[asterisk-dev] asterisk 1.4 developer needed

[Theo Belder]

Thanks so far. I've check the open file descriptors and they seems not to be
the problem (Around 250 with 5 concurrent calls).

Tilghman, can memory leaks and other unfreed memory allocations also be
detected with valgrind. Because I see sometimes in de asterisk logs after a
crash the following errors:
[Jul 13 09:19:49] WARNING[20779] udptl.c: No UDPTL ports remaining
[Jul 13 09:19:49] WARNING[20779] udptl.c: No UDPTL ports remaining
[Jul 13 09:19:49] WARNING[20779] udptl.c: No UDPTL ports remaining
Asterisk was terminated on signal 11 - SIGSEGV - Invalid memory segment
access

or:
[Sep 13 17:17:07] ERROR[14209]
/usr/src/SMR-core/applications/asterisk-1.4.41/include/asterisk/utils.h:
Memory Allocation Failure in function sip_alloc at line 4857 of chan_sip.c

When I check the coredump file (of the crash with the Memory alloction
failure messages), I've noticed that the coredump file is almost 540MB, is
that normal?


What I'm going to do is stresstest our development server and see whether
this is reproducable.

Best regards,
Theo


2011/9/13 Tilghman Lesher <tilghman at meg.abyt.es>

> 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.
>
> --
> Tilghman
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110914/972e33bc/attachment.htm>