[asterisk-bugs] [JIRA] (ASTERISK-22079) Segfault: INTERNAL_OBJ (user_data=0x6374652f) at astobj2.c:120

[Steve Davies (JIRA)]

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

Steve Davies commented on ASTERISK-22079:
-----------------------------------------

Just FYI, my scheduler comments above can be ignored - my mistake. Matt is of course correct that the scheduled item is removed from the sched list while being run, and is then re-added or freed after the run based on the event's return value.

Two alternative thoughts to throw out there:

1) Is it possible that the scheduled send_provisional_keepalive_full() run is waiting on a lock that is being held by __sip_destroy? The sched event's own pvt ref will keep the pvt from being freed, but by the time it gets the lock, pvt->owner may be invalid, and the pvt itself may be a useless skeleton of its former self. This assumes that it is possible to destroy the chan but leave pvt->owner set. I see that __sip_destroy does clear owner->tech_pvt, but relies on something else to clean up pvt->owner, which may or may not be significant. All other chan_sip instances of cleaning owner->tech_pvt also clean pvt->owner.

2) If update_provisional_keepalive() is called while send_provisional_keepalive_full() is waiting on the PVT lock, then pvt->provisional_keepalive_sched_id will be changed to a new sched_id value by update_provisional_keepalive(), but that new sched_id then may be overwritten with -1 by send_provisional_keepalive_full(), killing the pvt's reference to a schedule and "leaking" the reference.


This is a rare crash, and I've not been able to cause it even by intentionally adding a Wait(61) to the dialplan to encourage the use of send_provisional_keepalive_full().

                
> Segfault: INTERNAL_OBJ (user_data=0x6374652f) at astobj2.c:120
> --------------------------------------------------------------
>
>                 Key: ASTERISK-22079
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22079
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 1.8.23.0
>         Environment: Linux CentOS 5.9 32-bit as a VM on XenServer 5.6 SP2
>            Reporter: Jamuel Starkey
>            Assignee: Jamuel Starkey
>         Attachments: asterisk-22079-gdb-output.txt
>
>
> We discovered this segfault while running a debug build 1.8.23.0-rc1.  Although not entirely clear it's likely that this issue was triggered during an asterisk "reload" operation that would have been sent over AMI.
> Attaching the output of gdb (bt, bt full, thread apply all bt) as per the Debug guidelines found on the wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira