[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=214341#comment-214341 ] 

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

>From a read-though of the code, if the following happens, you will double-unref. This is described in very generic terms, and might not be possible, but it is my working theory... Comments are most welcome.

Thread 1
1) provisional_keepalive_sched fires send_provisional_keepalive()
2) Locking starts to happen
3) pvt is locked for a moment... wait

Thread 2
1) I have the PVT lock that you are waiting for
2) Something happens and I cancel provisional_keepalive_sched
3) I unref the PVT for that sched
4) I unlock the PVT

Thread 1
1) I get my lock and send a provisional keepalive
2) I set sched_id to -1
3) I unref the PVT for that sched

*BANG* the PVT was already unref'ed by thread 2 above and I just went negative :( Of course I may not be negative quite yet, that might happen later...

One "fix" might be to check for an un-changed value in provisional_keepalive_sched_id after you've grabbed the locks, and bail if it is changed. I think you also get a problem if update_provisional_keepalive() is called after the sched event has started as that might cause a similar double-unref.

In fact, if this is real, how many other places might this happen in Asterisk??? Perhaps you can shoot this down in flames for me?
                
> 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