Summary:ASTERISK-03932: Crash observed
Reporter:Matthias Urlichs (smurfix)Labels:
Date Opened:2005-04-13 14:46:22Date Closed:2011-06-07 14:00:48
Versions:Frequency of
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.


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) ) {

(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.