[Home]

Summary:ASTERISK-14506: Segfault in SVN revision 207360 chan_sip.c in in __ast_pthread_mutex_lock
Reporter:David Brillert (aragon)Labels:
Date Opened:2009-07-21 08:03:12Date Closed:2011-06-07 14:00:44
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb21072009crashpthread_lock1.txt
( 1) segfault14082009.txt
( 2) valgrind15544leaklog.txt
Description:Crashed here

0x00697412 in __ast_pthread_mutex_lock (filename=0x6f1e35 "chan_sip.c",
   lineno=1935, func=0x6f23c4 "retrans_pkt",
   mutex_name=0x6f23d0 "&pkt->owner->lock", t=0x40)
   at /dar/build/asterisk-1.4.26/include/asterisk/lock.h:354


****** ADDITIONAL INFORMATION ******

bt, bt full, thread apply all bt, attached
Comments:By: David Brillert (aragon) 2009-07-21 08:11:52

I think root cause is somewhere in r205877 | mmichelson | 2009-07-10 13:39:13 -0400 (Fri, 10 Jul 2009) | 40 lines
https://reviewboard.asterisk.org/r/308/
By: David Brillert (aragon) 2009-07-21 11:26:03

valgrind info attached.
Looks like ast_sched_runq is leaking
By: David Brillert (aragon) 2009-08-14 12:35:21

Crashed today under revision 211807
New backtrace attached
By: Jeff Peeler (jpeeler) 2009-11-06 15:18:36.000-0600

A "thread apply all bt" would be helpful as well as checking the address of pkt->owner (p pkt->owner in frame 0). For one of the backtraces the lock address is definitely invalid. Console debug output would also help.
By: David Brillert (aragon) 2009-11-06 15:24:33.000-0600

I haven't seen this crash since my last bug note.
But I no longer use r211807
This might be fixed in SVN.
I will upload thread apply all bt etc... if I ever see this crash again.
By: David Brillert (aragon) 2009-11-06 15:30:27.000-0600

In fact I have no issue if you close this bug because I haven't reproduced it since August and no longer use those revisions. Especially since you found nothing of use in the existing debug attachments.
By: Jeff Peeler (jpeeler) 2009-11-09 10:48:42.000-0600

Ok, I'll go ahead and close it then. It seems safe to do so since you haven't reproduced it in several months.