[asterisk-dev] strange segfault in bridging.c

[Klaus Darilion]

Am 10.02.2010 07:24, schrieb 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?

Yes. Without the log statements I have not experienced a crash. With log 
statements it crashes with a ~50% chance when the last participant left 
the conference (actually I tested only with 1 participant, so maybe it 
happens if any participants leave the conference).

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

Ok. I will try to add more pointer debugging log statements.

thanks
klaus

>
> Mark Michelson
>