Thanks so far. I've check the open file descriptors and they seems not to be the problem (Around 250 with 5 concurrent calls).<br><br>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:<br>
[Jul 13 09:19:49] WARNING[20779] udptl.c: No UDPTL ports remaining<br>[Jul 13 09:19:49] WARNING[20779] udptl.c: No UDPTL ports remaining<br>[Jul 13 09:19:49] WARNING[20779] udptl.c: No UDPTL ports remaining<br>Asterisk was terminated on signal 11 - SIGSEGV - Invalid memory segment access<br>
<br>or:<br>[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<br><br>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?<br>
<br><br>What I'm going to do is stresstest our development server and see whether this is reproducable.<br><br>Best regards,<br>Theo<br><br><br><div class="gmail_quote">2011/9/13 Tilghman Lesher <span dir="ltr"><<a href="mailto:tilghman@meg.abyt.es">tilghman@meg.abyt.es</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Tuesday, September 13, 2011 07:05:18 AM Theo Belder wrote:<br>
> We know that asterisk 1.4 isn't supported anymore but we receive each<br>
> week notices from systems about that asterisk is crashed at customer<br>
> locations.<br>
><br>
> When we check the core dump (DONT_OPTIMIZE is turned off) we see<br>
> often the following result of 'bt' command in gdb:<br>
> #0 0x008ad7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2<br>
> #1 0x008ed7a5 in raise () from /lib/tls/libc.so.6<br>
> #2 0x008ef209 in abort () from /lib/tls/libc.so.6<br>
> #3 0x0092171a in __libc_message () from /lib/tls/libc.so.6<br>
> #4 0x00927fbf in _int_free () from /lib/tls/libc.so.6<br>
> #5 0x0092833a in free () from /lib/tls/libc.so.6<br>
> #6 0x080aeb91 in __ast_module_user_remove (mod=0x9ecff4, u=0x9ee840)<br>
> at loader.c:224<br>
> #7 0x00147028 in local_hangup (ast=0xa17e670) at chan_local.c:682<br>
> #8 0x08087df1 in ast_hangup (chan=0xa17e670) at channel.c:1708<br>
> #9 0x0015f3fa in dial_exec_full (chan=0x9f82660, data=Variable<br>
> "data" is not available.<br>
> ) at app_dial.c:1926<br>
> #10 0x001623b4 in dial_exec (chan=0x0, data=0x6) at app_dial.c:1967<br>
> #11 0x080cec70 in pbx_extension_helper (c=0x9f82660, con=Variable<br>
> "con" is not available.<br>
> ) at<br>
> /usr/src/SMR-core/applications/asterisk-1.4.41-patched/include/asteri<br>
> sk/strings.h:36 #12 0x080d37db in __ast_pbx_run (c=0x9f82660) at<br>
> pbx.c:2371<br>
> #13 0x080d591e in pbx_thread (data=0x9f82660) at pbx.c:2693<br>
> #14 0x081068c5 in dummy_start (data=0x6) at utils.c:856<br>
> #15 0x00c48371 in start_thread () from /lib/tls/libpthread.so.0<br>
> #16 0x0098dffe in clone () from /lib/tls/libc.so.6<br>
><br>
> At most systems asterisk 1.4.41 or 1.4.42 is running.<br>
><br>
> Is somebody willing to help us to resolve these crashes?<br>
<br>
</div></div>If this is easily reproducible, kindly run the process under Valgrind,<br>
redirecting valgrind output to a file. This backtrace suggests that the<br>
malloc structures are being corrupted, which occurs when something<br>
writes over either end of an allocated memory space.<br>
<font color="#888888"><br>
--<br>
Tilghman<br>
</font><div><div></div><div class="h5"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br>