[asterisk-bugs] [Asterisk 0009520]: realtime prune (and others) may segfault asterisk (timing issue)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9520 
====================================================================== 
Reported By:                kryptolus
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   9520
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.2  
SVN Revision (number only!): 61305 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             04-11-2007 07:31 CDT
Last Modified:              11-09-2007 08:03 CST
====================================================================== 
Summary:                    realtime prune (and others) may segfault asterisk
(timing issue)
Description: 
The function expire_register doesn't do any locking before mucking with the
peer. 
If it gets pre-empted, there's a chance that the peer might be destroyed
before the control returns to expire_register. 

If you execute a "prune realtime peer" at the right time, asterisk will
segfault. It is not limited to just this however, as I have experienced
several segfaults with this signature without any intervention. However,
looking at the code I can only see a problem with the pruning code, I don't
see any possible issues with any other place in sip.

My patch queues up peers to be destroyed and they are ultimately destroyed
from the monitor thread which should guarantee that expire_register cannot
be running  at the same time. The other alternative is to add a check to
expire_register to check if peer is still inside the peer list. However,
that has potential to impact performance because that check would block a
lot of things on every expire.




====================================================================== 

---------------------------------------------------------------------- 
 ys - 11-09-07 08:03  
---------------------------------------------------------------------- 
This is still exist in 1.4.13.

Sometimes (after sip reload) if i have outgoing sip registrations.
I see coredump:

http://bugs.digium.com/view.php?id=0  0x285df62e in ast_mutex_lock (pmutex=0x5c)
at lock.h:716
No locals.
http://bugs.digium.com/view.php?id=1  0x285f7159 in expire_register
(data=0x81ff000) at chan_sip.c:7741
        newcount = 0
        peer = (struct sip_peer *) 0x0
        __PRETTY_FUNCTION__ = "expire_register"
http://bugs.digium.com/view.php?id=2  0x080e15dc in ast_sched_runq
(con=0x81bab40) at sched.c:359
        current = (struct sched *) 0x81dbe20
        tv = {tv_sec = 1194613236, tv_usec = 648355}
        numevents = 0
        res = 677590056
http://bugs.digium.com/view.php?id=3  0x28617b35 in do_monitor (data=0x0) at
chan_sip.c:15389
        res = 0
        sip = (struct sip_pvt *) 0x0
        peer = (struct sip_peer *) 0x0
        t = 1194613236
        fastrestart = 0
        lastpeernum = -1
        curpeernum = 14
        reloading = 0
        __PRETTY_FUNCTION__ = "do_monitor"
http://bugs.digium.com/view.php?id=4  0x080eeefd in dummy_start (data=0x81bf160)
at utils.c:805
        ret = (void *) 0x0
       a = {start_routine = 0x2861758c <do_monitor>, data = 0x0,
  name = 0x81bee80 "do_monitor", ' ' <repeats 11 times>, "started at
[15443] chan_sip.c restart_monitor()"}
http://bugs.digium.com/view.php?id=5  0x282c33a5 in pthread_create () from
/lib/libpthread.so.2
No symbol table info available.
http://bugs.digium.com/view.php?id=6  0x28380137 in _ctx_start () from
/lib/libc.so.6
No symbol table info available.
(gdb) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-09-07 08:03  ys             Note Added: 0073435                          
======================================================================