Summary:	ASTERISK-03932: Crash observed
Reporter:	Matthias Urlichs (smurfix)	Labels:
Date Opened:	2005-04-13 14:46:22	Date Closed:	2011-06-07 14:00:48
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) misdn_crash.patch
Description:	I saw chan_misdn crash Asterisk a few times now. It happened in ast_queue_frame(), called from the end of chan_misdn_write_frm(). The problem was that chan->pvt was NULL. ****** ADDITIONAL INFORMATION ****** I don't know if that's a chan_misdn bug or an Asterisk core bug. However, this looks like it might be a locking problem (chan_misdn does test chan>pvt, but obviously not under any lock), so I submit it here.
Comments:	By: Clod Patry (junky) 2005-04-13 14:48:26 Could u attach ur backtrace from core? By: Paul Cadach (pcadach) 2005-04-13 14:52:43 This should be fixed in chan_misdn not within Asterisk core because ast_read() (as I understand) should be simple as possible. By: Matthias Urlichs (smurfix) 2005-04-14 00:55:44 I'll try to recreate the backtrace if it happens again; I overwrote the asterisk binary when I installed the replacement. :-/ However, it seems that chan->pvt is supposed to be accessed under lock. Thus, fixing the problem in chan_misdn isn't possible because some other thread can free it before you lock the channel and use the ->pvt field in ast_queue_frame(). Besides, chan_misdn.c already has a test which looks like it's checking for the existence of ->pvt:  if (tmp && tmp->ast && MISDN_ASTERISK_PVT (tmp->ast) && MISDN_ASTERISK_TECH_PVT(tmp->ast) ) {    ast_queue_frame(...)  } (MISDN_ASTERISK_PVT(x) expands to x->pvt.) Thus I think that this is exactly what happened, and the test in my patch is correct and should be added. By: crich (crich) 2005-04-14 06:51:50 I think also its a locking problem. The funny thing is, that in asterisk head revision this problem never occured anymore, i think this is because of the new alertpipe signalling mechanism. Indeed chan_misdn tries to test wether ast->pvt exists before it queues a frame with ast_queue_frame, also I agree with smurfix thats hardly possible for chan_misdn to avoid this segfault. Btw. let me explain when this bug occurs exactly: The Problem occured often with asterisk stable in that form: After starting the asterisk (mostly direct after a reboot of the system), everything looks fine. After the first call, directly after receiving a disconnect (which leads to a hangup) the asterisk crashes with a segfault. By: Mark Spencer (markster) 2005-04-15 00:48:30 MISDN is not part of asterisk, and this patch is just glossing over a bug in MISDN , not a bug in Asterisk.  The bug tracker is only for tracking bugs within Asterisk and not with third party non-disclaimed modules.