[asterisk-dev] 1.6.1.10-rc1 crash on a VOLUME() func

[Pavel Troller]

> Hi Kaloyan,
> 
> > 
> > Looking a bit more at the code ...
> > 
> >  /* Feed in frame to manipulation */
> >  	if (audiohook->manipulate_callback(audiohook, chan, middle_frame, direction)) {
> >  	ast_frfree(middle_frame);
> >  	middle_frame = NULL;
> >  	}
> > 
> > so if there is more than one manipulate audiohook and the first one fails
> > (returns nonzero), the middle_frame is set to NULL, but then in
> > volume_callback we have:
> > 
> >    if (frame->frametype == AST_FRAME_DTMF) {
> > 
> > could this be the reason for the crash (or separate issue)? If so then few
> > lines before this check there should be:
> > 
> >  if (audiohook->status == AST_AUDIOHOOK_STATUS_DONE || !frame)
> >  	return 0;
> > 
> 
> Yes, it looks very suspiciously, but I'm afraid that it also isn't a primary
> reason for the crash. It seems more like a separate issue, which doesn't happen
> here. This case would cause a segfault (accessing memory near zero), while my
> crash is a double free (or a memlist corruption), detected by glibc. So, it
> looks like some memory gets freed, but the pointer is not zeroed and then the
> same memory is attempted to free again. Now I'm configuring my build to be able
> to obtain a usable backtrace.
> 

Hi!
 Still no backtrace. I've recompiled asterisk with full debug symbols, it's
15MB long, but the backtrace of the crash is still stupid:

(gdb) bt
#0  0xb7f1a424 in __kernel_vsyscall ()
#1  0xb720151c in raise () from /lib/libc.so.6
#2  0xb7341ff4 in ?? () from /lib/libc.so.6
#3  0x00000400 in ?? ()
#4  0xb5aee1fc in ?? ()
#5  0xb5aee858 in ?? ()
#6  0xb7203448 in abort () from /lib/libc.so.6
#7  0xb7341ff4 in ?? () from /lib/libc.so.6
#8  0x00000000 in ?? ()
(gdb)

 It's probably because of the atypical crash scenario (the crash forced by
glibc itself). When I tried to link asterisk statically with libc_g.a, it
didn't start, it froze somewhere in the futex() syscall and sit there forever.

BTW, Without my intervention, func_volume.so didn't load, when the asterisk
was compiled without optimization (with debug), there were undefined symbols
(ast_audiohok_volume_set etc.). The func_volume.i file contained the following:

int ast_audiohook_volume_set(struct ast_channel *chan, enum ast_audiohook_direction direction, int volume); extern inline int ast_audiohook_volume_set(struct ast_channel *chan, enum ast_audiohook_direction direction, int volume) { return ast_audiohook_volume_full(chan, direction, volume, AST_AUDIOHOOK_VOLUME_SET, 0, 0, 0, 0); }

I had to manually remove the "extern" modifier to delete the symbol from
external linker requirements and to force local inlining. My gcc is 4.3.3.
After that, func_volume.so was able to be loaded and caused a crash as
usually, but still with such a dumb backtrace.

  What do you prefer ? To run a valgrind check without MALLOC_DEBUG, which
will hopefully trigger the crash, or to to run it with it, which probably
will not crash ?

  With regards,
    Pavel