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