|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:12||Date Closed:||2011-06-07 14:00:44|
|Environment:||Attachments:||( 0) gdb21072009crashpthread_lock1.txt|
( 1) segfault14082009.txt
( 2) valgrind15544leaklog.txt
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)
****** 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
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.