[asterisk-bugs] [Asterisk 0015465]: crash in bridging api
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Aug 31 08:27:40 CDT 2009
The following issue requires your FEEDBACK.
======================================================================
https://issues.asterisk.org/view.php?id=15465
======================================================================
Reported By: fnordian
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 15465
Category: Core/General
Reproducibility: sometimes
Severity: crash
Priority: normal
Status: feedback
Asterisk Version: SVN
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.2
SVN Revision (number only!): 204918
Request Review:
======================================================================
Date Submitted: 2009-07-08 07:00 CDT
Last Modified: 2009-08-31 08:27 CDT
======================================================================
Summary: crash in bridging api
Description:
There's a racecondition in smart_bridge_operation(). I do not understand
this function completely, but it seems like one of it's purposes is to
change a bridge's technology. For doing so it stops the bridge->thread
before working on it. Stopping is done by setting a flag and sending a
signal. What's missing there imho is a pthread_join to assure the thread is
really gone.
I noticed crashes when doing transfers from and to the bridges and I guess
one of the reasons is this bug:
(gdb) bt full
https://issues.asterisk.org/view.php?id=0 0x0000000000000024 in ?? ()
No symbol table info available.
https://issues.asterisk.org/view.php?id=1 0x00002aaab677483d in
softmix_bridge_thread (bridge=0x2aaab7819e88)
at bridge_softmix.c:270
sc = (struct softmix_channel *) 0x2aaab780a7d0
bridge_channel = (struct ast_bridge_channel *) 0x0
buf = {0 <repeats 320 times>}
timeout = -1
timer = (struct ast_timer *) 0x2aaab7833370
timingfd = 40
https://issues.asterisk.org/view.php?id=2 0x000000000043ae34 in bridge_thread
(data=<value optimized out>) at
bridging.c:381
bridge = (struct ast_bridge *) 0x2aaab7819e88
res = <value optimized out>
__PRETTY_FUNCTION__ = "bridge_thread"
https://issues.asterisk.org/view.php?id=3 0x00000000004fb96c in dummy_start
(data=<value optimized out>) at
utils.c:968
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {46912711515904,
0, 0,
0, 1089483408, 1089486848, 1089483072, 5224786}, __mask_was_saved
= 0}},
__pad = {0x40f03200, 0x0, 0x0, 0x0}}
__cancel_arg = (void *) 0x40f03960
not_first_call = <value optimized out>
ret = <value optimized out>
https://issues.asterisk.org/view.php?id=4 0x00002b56877dff1a in start_thread ()
from /lib/libpthread.so.0
No symbol table info available.
https://issues.asterisk.org/view.php?id=5 0x00002b56873245d2 in clone () from
/lib/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=6 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) p *bridge->technology
$14 = {name = 0x2aaab1ada807 "multiplexed_bridge", capabilities = 2,
preference = AST_BRIDGE_PREFERENCE_HIGH,
create = 0x2aaab1ad9bc0 <multiplexed_bridge_create>,
destroy = 0x2aaab1ad9fc0 <multiplexed_bridge_destroy>,
join = 0x2aaab1ad9a90 <multiplexed_bridge_join>,
leave = 0x2aaab1ad97d0 <multiplexed_bridge_leave>,
suspend = 0x2aaab1ad9740 <multiplexed_bridge_suspend>,
unsuspend = 0x2aaab1ad96b0 <multiplexed_bridge_unsuspend>, compatible =
0,
write = 0x2aaab1ad9370 <multiplexed_bridge_write>, fd = 0, thread = 0,
poke = 0,
formats = 1073741823, suspended = 0, mod = 0x9c9a80, entry = {next =
0x2aaaaedaf300}}
The crash is in bridge_softmix, working on a bridge which thinks it's
bridge_multiplexed.
======================================================================
----------------------------------------------------------------------
(0109831) lmadsen (administrator) - 2009-08-31 08:27
https://issues.asterisk.org/view.php?id=15465#c109831
----------------------------------------------------------------------
Can you please provide a backtrace with DONT_OPTIMIZE enabled in
menuselect? It will make the backtrace you're providing much more useful.
Additionally, do you have any particular scenarios that you can provide in
order to allow us to attempt to reproduce?
Thanks!
Issue History
Date Modified Username Field Change
======================================================================
2009-08-31 08:27 lmadsen Note Added: 0109831
2009-08-31 08:27 lmadsen Status new => feedback
======================================================================
More information about the asterisk-bugs
mailing list