[asterisk-dev] strange segfault in bridging.c

[Mark Michelson]

Klaus Darilion wrote:
> SVN-branch-1.6.2-r245626M (todays SVN)
>
> Hi!
>
> I just play around with the bridging framework and as soon as I add 
> some log statements Asterisk segfaults. Here is the backtrace:
>
> #0  0x080874d6 in find_bridge_channel (bridge=0x0, chan=0x92dc590) at 
> bridging.c:208
> 208             AST_LIST_TRAVERSE(&bridge->channels, bridge_channel, 
> entry) {
> (gdb) bt
> #0  0x080874d6 in find_bridge_channel (bridge=0x0, chan=0x92dc590) at 
> bridging.c:208
> #1  0x08087730 in ast_bridge_handle_trip (bridge=0x0, 
> bridge_channel=0x0, chan=0x92dc590, outfd=-1) at bridging.c:280
> #2  0xb757c6d8 in multiplexed_thread_function (data=0x92f15a0) at 
> bridge_multiplexed.c:236
> #3  0x08159ab9 in dummy_start (data=0xb7845e88) at utils.c:968
> #4  0xb7b70f3b in start_thread () from /lib/libpthread.so.0
> #5  0xb7d8bbee in clone () from /lib/libc.so.6
>
>
> I have attached the diff of my modifications. It is just logging of 
> pointers, so I am pretty sure my log statements are fine.
>
> Maybe it be that there is a race condition between threads which only 
> happens if on thread is delayed by logging?
>
> regards
> Klaus
Your changes look pretty innocuous to me. It seems weird that the first 
argument to ast_bridge_handle_trip would be NULL since we just checked 
to be sure that it was non-NULL in multiplexed_thread_function. Do I 
understand you correctly that the crashes only occur when your debug 
lines have been added?

Valgrind may help with this, although I have a feeling it's just going 
to tell you that address 0x0 is not stacked, heaped, or recently freed. 
Something else that may help is to place debugging statements at places 
where a channel's bridge can be set NULL to see if that is what is 
happening in a separate thread. The bridge_channel->chan->bridge = NULL 
statement in bridge_channel_join in bridging.c seems a bit suspicious to 
me, though I admit that my knowledge of the bridging API is tenuous.

Mark Michelson