[asterisk-bugs] [Asterisk 0014189]: segmentation fault in local_queue_frame at chan_local.c:172
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Jan 14 13:25:15 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14189
======================================================================
Reported By: sascha
Assigned To: putnopvut
======================================================================
Project: Asterisk
Issue ID: 14189
Category: Channels/chan_local
Reproducibility: random
Severity: crash
Priority: normal
Status: ready for review
Asterisk Version: 1.4.23-rc3
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-01-07 10:16 CST
Last Modified: 2009-01-14 13:25 CST
======================================================================
Summary: segmentation fault in local_queue_frame at
chan_local.c:172
Description:
happened for the second time now today, but I have no idea what triggered
it:
Failed to read a valid object file image from memory.
Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg
-c'.
Program terminated with signal 11, Segmentation fault.
http://bugs.digium.com/view.php?id=0 0x00002aaab2b1b5c6 in local_queue_frame
(p=0x2aaab7c09eb0,
isoutbound=1, f=0x84a418, us=0x2aaab7c011d0, us_locked=1)
at chan_local.c:172
172 if (us && us->generator && other->generator)
(gdb) bt
http://bugs.digium.com/view.php?id=0 0x00002aaab2b1b5c6 in local_queue_frame
(p=0x2aaab7c09eb0,
isoutbound=1, f=0x84a418, us=0x2aaab7c011d0, us_locked=1)
at chan_local.c:172
http://bugs.digium.com/view.php?id=1 0x00002aaab2b1bf87 in local_write
(ast=0x2aaab7c011d0, f=0x84a418) at
chan_local.c:324
http://bugs.digium.com/view.php?id=2 0x000000000043def8 in ast_write
(chan=0x2aaab7c011d0, fr=<value
optimized out>) at channel.c:2878
http://bugs.digium.com/view.php?id=3 0x00000000004619d9 in playtones_generator
(chan=0x2aaab7c011d0,
data=0x83ba20, len=320, samples=160) at indications.c:191
http://bugs.digium.com/view.php?id=4 0x000000000043c6e5 in generator_force
(data=<value optimized out>) at
channel.c:1623
http://bugs.digium.com/view.php?id=5 0x000000000043ff8e in __ast_read
(chan=0x2aaab7c011d0, dropaudio=0) at
channel.c:2104
http://bugs.digium.com/view.php?id=6 0x0000000000440d66 in
ast_safe_sleep_conditional (chan=0x2aaab7c011d0,
ms=20000, cond=0, data=0x0) at channel.c:2438
http://bugs.digium.com/view.php?id=7 0x00000000004779af in wait_for_hangup
(chan=0x2aaab7c011d0,
data=<value optimized out>) at pbx.c:5364
http://bugs.digium.com/view.php?id=8 0x0000000000477a5f in pbx_builtin_busy
(chan=0x2aaab7c011d0,
data=0x423766b0) at pbx.c:5403
http://bugs.digium.com/view.php?id=9 0x000000000048174b in pbx_extension_helper
(c=0x2aaab7c011d0,
con=<value optimized out>, context=0x2aaab7c01420 "macro-exten-vm",
exten=0x2aaab7c01470 "s-BUSY", priority=4, label=<value optimized
out>, callerid=0x2aaab7b16840 "03692350524", action=E_SPAWN)
at pbx.c:537
http://bugs.digium.com/view.php?id=10 0x0000000000481b83 in ast_spawn_extension
(c=0x2aaab7c09eb0,
context=0x2aaab7c09f88 "?\021??*",
exten=0x1 <Address 0x1 out of bounds>, priority=1, callerid=<value
optimized out>) at pbx.c:2318
http://bugs.digium.com/view.php?id=11 0x00002aaab4a25b9a in _macro_exec
(chan=0x2aaab7c011d0, data=<value
optimized out>, exclusive=0) at app_macro.c:346
http://bugs.digium.com/view.php?id=12 0x000000000048174b in pbx_extension_helper
(c=0x2aaab7c011d0,
con=<value optimized out>, context=0x2aaab7c01420 "macro-exten-vm",
exten=0x2aaab7c01470 "s-BUSY", priority=1, label=<value optimized
out>, callerid=0x2aaab7b16840 "03692350524", action=E_SPAWN)
at pbx.c:537
http://bugs.digium.com/view.php?id=13 0x0000000000483938 in __ast_pbx_run
(c=0x2aaab7c011d0) at pbx.c:2318
http://bugs.digium.com/view.php?id=14 0x0000000000484639 in pbx_thread
(data=0x2aaab7c09eb0) at pbx.c:2622
http://bugs.digium.com/view.php?id=15 0x00000000004aee6c in dummy_start
(data=<value optimized out>) at
utils.c:856
http://bugs.digium.com/view.php?id=16 0x00002aad0566ef1a in start_thread () from
/lib/libpthread.so.0
http://bugs.digium.com/view.php?id=17 0x00002aad05c3b5d2 in clone () from
/lib/libc.so.6
http://bugs.digium.com/view.php?id=18 0x0000000000000000 in ?? ()
in case it matters: it's on a debian linux, amd64, 2.6.24+13~etchnhalf.1
kernel. connected to the PSTN via mISDN 1.1.8 using a B410P.
======================================================================
----------------------------------------------------------------------
(0097778) putnopvut (administrator) - 2009-01-14 13:25
http://bugs.digium.com/view.php?id=14189#c97778
----------------------------------------------------------------------
blitzrage: mnicholson put it well. It is not invasive at all.
I'm not 100% sure of all the details as to why one or both of p->chan or
p->owner may be NULL, but there is a lot of weird stuff that goes on in
chan_local. For instance, when a call is bridged using chan_local, the
endpoint that p->chan was communicating with masquerades into the p->owner
channel and p->chan is hung up. If there was a pending frame waiting to be
queued onto p->chan, I suspect that could be a reason why it could be
NULL.
The one thing that made me write the patch this way was that there already
was logic in local_queue_frame to handle the case of p->chan being NULL, so
I took that to mean that p->chan being NULL is not an error condition. The
new code which checks for the presence of generators on both channels was
added above this NULL check, so my patch to move it down below that seemed
correct to me.
Issue History
Date Modified Username Field Change
======================================================================
2009-01-14 13:25 putnopvut Note Added: 0097778
======================================================================
More information about the asterisk-bugs
mailing list