[asterisk-bugs] [JIRA] (ASTERISK-20929) Core-dump on SIP BYE for an invalid call transaction

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201406#comment-201406 ] 

Matt Jordan commented on ASTERISK-20929:
----------------------------------------

So this is a bit odd. From the backtrace, it appears as if {{sip_queue_hangup_cause}} has an owning channel that has already been reclaimed - the fact that name appears to have garbage in it when it strdup'd the channel name onto the stack if a fairly bad sign.

Could you include a pcap of the SIP message traffic that reproduces this? The fact that it isn't crashing in 1.8 is indicative of something rather subtle in the channel reference counting, and a pcap will help us try to reproduce the exact sequence of events that leads up to this.
                
> Core-dump on SIP BYE for an invalid call transaction
> ----------------------------------------------------
>
>                 Key: ASTERISK-20929
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20929
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.1.0, 11.1.1, 11.1.2
>         Environment: Linux/2.6.32-279.19.1.el6.i686 #1 SMP Wed Dec 19 04:30:58 UTC 2012 i686 i686 i386 GNU/Linux
>            Reporter: Kristopher Lalletti
>         Attachments: core-20130111-01.txt
>
>
> We've been noticing core-dumps on Asterisk since we migrated from 1.8.x to 11.1.x late last December, which caused us to rollback to 1.8.19.1 in order to return into a stable state.
> We noticed a very specific (mis)behaviour of our soft-switch to which when it signaled a SIP BYE message to ASterisk with an invalid Call-ID, Asterisk would systematically segfault. 
> When we backtracked to 1.8.19.1, at least Asterisk will return a "481 Call leg/transaction does not exist" and not die.
> Included is the core-dump backtrace showing the SIP BYE transaction causing Asterisk 11.1.1 to segfault.  
> PS: I also have a system running 11.1.2 which is equally having the same symptoms, but I have yet to capture a tangible backtrace.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira