[SR-Users] 4.4: Kamailio crashes at start - sometimes

[Daniel-Constantin Mierla]

Hello,

the backtrace is from doing shutdown cleanup, triggered because it
couldn't start for other reason, but it doesn't provide any useful
information. Are all the cores giving similar backtrace?

Can you try with '-x qm' just to see if there is a memory overwriting
issue around?

Cheers,
Daniel


On 25/05/16 15:42, Sebastian Damm wrote:
> Hi,
>
> it is definitely no memory or open files issue. I stopped all
> processes and tried to start one of the faulty instances by itself,
> without luck.
>
> Actually, there are core files. I don't know whether they say
> something interesting, but I just saw that each start attempt produced
> a core file.
>
> This is the backtrace of one of them:
>
> root at kammel:~# gdb /usr/sbin/kamailio
> /var/cores/core_kamailio_24894_6_110_1464180675
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/kamailio...Reading symbols from
> /usr/lib/debug/.build-id/0e/a2651a480b84540fc37d4d0d640aa3a4db078c.debug...done.
> done.
> [New LWP 24894]
>
> warning: Can't read pathname for load map: Input/output error.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/sbin/kamailio -f
> /etc/kamailio/kamailio_sip_lb_sipconnect_de_v6_1.cfg -P /'.
> Program terminated with signal 6, Aborted.
> #0  0x00007fef1812b125 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007fef1812b125 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007fef1812e3a0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x00000000004ab7d9 in sig_alarm_abort (signo=<optimized out>) at main.c:649
> #3  <signal handler called>
> #4  0x00007fef181d3b77 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
> #5  0x00007fef0fc69d50 in futex_get (lock=<optimized out>) at
> ../../parser/../mem/../futexlock.h:108
> #6  mod_destroy () at rtpengine.c:1970
> #7  0x0000000000580092 in destroy_modules () at sr_module.c:811
> #8  0x00000000004ac407 in cleanup (show_status=show_status at entry=1) at
> main.c:524
> #9  0x00000000004acf4f in shutdown_children (show_status=1, sig=15) at
> main.c:666
> #10 0x00000000004adac7 in handle_sigs () at main.c:758
> #11 0x00000000004b22e6 in main_loop () at main.c:1733
> #12 0x0000000000427e2b in main (argc=<optimized out>, argv=<optimized
> out>) at main.c:2616
>
>
> Best Regards,
> Sebastian

-- 
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160526/2b724e99/attachment.html>