| Summary: | ASTERISK-20145: Segfault in iax_pvt_callid_get | ||
| Reporter: | Birger "WIMPy" Harzenetter (wimpy) | Labels: | |
| Date Opened: | 2012-07-17 21:37:49 | Date Closed: | 2012-07-20 14:44:21 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_iax2 |
| Versions: | SVN | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) pastebin | |
| Description: | This happened after a call was terminated. I have no idea what contributed to this happening and cannot reproduce, but a segfault is always bad. | ||
| Comments: | By: Birger "WIMPy" Harzenetter (wimpy) 2012-07-17 21:38:23.473-0500 pastebin contains backtrace By: Matt Jordan (mjordan) 2012-07-19 17:31:27.455-0500 It looks like the chan_iax2_pvt pointer in the iaxs array for the call number identified for that IAX2 full frame was either already NULL or got set to NULL before we relocked the mutex for it. This should only be an issue in trunk. By: Jonathan Rose (jrose) 2012-07-20 14:12:19.501-0500 This was just a bad assumption on my part. I think I must have thought that taking the lock meant a channel was in that position. Looking at where I had invoked iax_pvt_callid_get, it's pretty clear that this isn't the case and it's still possible for a call to 'arrive for a nonexistent destination'. Fix is trivial, I just need to check for the presence of the channel before trying to get a call ID out of it. EDIT: I committed a fix. It shouldn't be able to happen anymore. | ||