[asterisk-dev] asterisk 1.4 developer needed

[Russell Bryant]

On Tue, Sep 13, 2011 at 2:15 PM, Tilghman Lesher <tilghman at meg.abyt.es> wrote:
> On Tuesday, September 13, 2011 07:05:18 AM Theo Belder wrote:
>> We know that asterisk 1.4 isn't supported anymore but we receive each
>> week notices from systems about that asterisk is crashed at customer
>> locations.
>>
>> When we check the core dump (DONT_OPTIMIZE is turned off) we see
>> often the following result of 'bt' command in gdb:
>> #0  0x008ad7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
>> #1  0x008ed7a5 in raise () from /lib/tls/libc.so.6
>> #2  0x008ef209 in abort () from /lib/tls/libc.so.6
>> #3  0x0092171a in __libc_message () from /lib/tls/libc.so.6
>> #4  0x00927fbf in _int_free () from /lib/tls/libc.so.6
>> #5  0x0092833a in free () from /lib/tls/libc.so.6
>> #6  0x080aeb91 in __ast_module_user_remove (mod=0x9ecff4, u=0x9ee840)
>> at loader.c:224
>> #7  0x00147028 in local_hangup (ast=0xa17e670) at chan_local.c:682
>> #8  0x08087df1 in ast_hangup (chan=0xa17e670) at channel.c:1708
>> #9  0x0015f3fa in dial_exec_full (chan=0x9f82660, data=Variable
>> "data" is not available.
>> ) at app_dial.c:1926
>> #10 0x001623b4 in dial_exec (chan=0x0, data=0x6) at app_dial.c:1967
>> #11 0x080cec70 in pbx_extension_helper (c=0x9f82660, con=Variable
>> "con" is not available.
>> ) at
>> /usr/src/SMR-core/applications/asterisk-1.4.41-patched/include/asteri
>> sk/strings.h:36 #12 0x080d37db in __ast_pbx_run (c=0x9f82660) at
>> pbx.c:2371
>> #13 0x080d591e in pbx_thread (data=0x9f82660) at pbx.c:2693
>> #14 0x081068c5 in dummy_start (data=0x6) at utils.c:856
>> #15 0x00c48371 in start_thread () from /lib/tls/libpthread.so.0
>> #16 0x0098dffe in clone () from /lib/tls/libc.so.6
>>
>> At most systems asterisk 1.4.41 or 1.4.42 is running.
>>
>> Is somebody willing to help us to resolve these crashes?
>
> If this is easily reproducible, kindly run the process under Valgrind,
> redirecting valgrind output to a file.  This backtrace suggests that the
> malloc structures are being corrupted, which occurs when something
> writes over either end of an allocated memory space.

There a whole bunch of important fixes in chan_local between 1.4 and
later versions.  I would try backporting chan_local from 1.8 to see if
that fixes it.

-- 
Russell Bryant