[Home]

Summary:ASTERISK-16679: [patch] crash in __ast_manager_event_multichan
Reporter:Kristijan Vrban (vrban)Labels:
Date Opened:2010-09-15 02:59:32Date Closed:2010-10-12 11:00:07
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb_2.txt
( 1) gdb_4.txt
( 2) gdb_with_libpthread.so_debug.txt
( 3) gdb.txt
( 4) issue_17994.patch
( 5) mansession_locking_fix.diff
Description:Hello, today i got this core. See gdb output in gdb.txt
Comments:By: Kristijan Vrban (vrban) 2010-09-20 04:54:42

same core again, see gdb_2.txt
By: Kristijan Vrban (vrban) 2010-09-20 10:04:38

i think, this crash happen, because under certain circumstances the chan->uniqueid
is not/or not yet set. so i explicit check chan->uniqueid, not only chan.

When i see "chan->uniqueid is fucked\n" the next day in my log, and asterisk is still not crashed, then the patch works.


By: Kristijan Vrban (vrban) 2010-09-21 09:21:32

no, my simple patch does not fix the issue ;(

see latest gdb_4.txt
By: Kristijan Vrban (vrban) 2010-09-21 12:22:38

my patch was total useless, because i have overlooked, that the crash is in manager.c:4836 in pthread_kill

Perhaps because the thread does not exists not any more for some obscure reason?
By: Kristijan Vrban (vrban) 2010-09-22 12:18:48

check latest gdb_with_libpthread.so_debug where if have also debugging symbols enabled for libpthread.so where the crash happen.

the orginal line number in 1.8-beta5 in manager.c is 4836
not manager.c:4842 you see in the gdb output, because i wrote some debugging code into manager.c
By: Kristijan Vrban (vrban) 2010-09-30 07:28:27

Since some days i switched back to *-1.6

No more crashs since now. So it is definitive a 1.8 issue only
By: David Vossel (dvossel) 2010-10-07 11:03:51

Yep, this is definitely a 1.8 issue.  I have a good idea of what is going on.  I'll have a patch up for testing shortly.
By: David Vossel (dvossel) 2010-10-07 12:44:12

I uploaded a patch.  Please test and report your results.
By: Kristijan Vrban (vrban) 2010-10-08 11:59:47

hello dvossel, i installed 1.8-rc3 with the patch. the next few days will give an answer.
By: Leif Madsen (lmadsen) 2010-10-12 08:34:24

Ping? :)
By: Kristijan Vrban (vrban) 2010-10-12 10:44:57

pong :)

since two day it is in production. no crash so far. looks good
By: Digium Subversion (svnbot) 2010-10-12 10:58:58

Repository: asterisk
Revision: 291227

U   branches/1.8/main/manager.c

------------------------------------------------------------------------
r291227 | dvossel | 2010-10-12 10:58:57 -0500 (Tue, 12 Oct 2010) | 16 lines

Fixes manager.c crash.

This issue was caused by improper use of the mansession lock and
manession_session lock.  These two structures are confusing to begin
with so I'm not surprised this occurred.  I fixed this by consistently
making sure we use each of these locks only to protect the data
in the corresponding structure.  We had mismatched usage of these
locks which resulted in no mutual exclusivity occurring at all.


(closes issue ASTERISK-16679)
Reported by: vrban
Patches:
     mansession_locking_fix.diff uploaded by dvossel (license 671)
Tested by: vrban

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291227
By: Digium Subversion (svnbot) 2010-10-12 11:00:07

Repository: asterisk
Revision: 291228

_U  trunk/
U   trunk/main/manager.c

------------------------------------------------------------------------
r291228 | dvossel | 2010-10-12 11:00:06 -0500 (Tue, 12 Oct 2010) | 23 lines

Merged revisions 291227 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r291227 | dvossel | 2010-10-12 10:58:56 -0500 (Tue, 12 Oct 2010) | 16 lines
 
 Fixes manager.c crash.
 
 This issue was caused by improper use of the mansession lock and
 manession_session lock.  These two structures are confusing to begin
 with so I'm not surprised this occurred.  I fixed this by consistently
 making sure we use each of these locks only to protect the data
 in the corresponding structure.  We had mismatched usage of these
 locks which resulted in no mutual exclusivity occurring at all.
 
 
 (closes issue ASTERISK-16679)
 Reported by: vrban
 Patches:
       mansession_locking_fix.diff uploaded by dvossel (license 671)
 Tested by: vrban
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=291228