[sr-dev] Kamailio crash

[Alex Balashov]

So, my interpretation of this backtrace is that Kamailio simply crashed 
during what would otherwise be ordinary unwinding of TM hash table 
allocation. I suppose that means I should try to figure out why Kamailio 
shut down in the first place, i.e. from the logging.

On 04/23/2015 03:26 AM, Alex Balashov wrote:

> Hello,
>
> I just got this crash:
>
> (gdb) where
> #0  0x00007fc3c1319625 in raise () from /lib64/libc.so.6
> #1  0x00007fc3c131ae05 in abort () from /lib64/libc.so.6
> #2  0x0000000000619d31 in fm_free (qm=0x7fc1b6ffa000, p=0x1e11a02400000000,
>      file=0x7fc3bf8ebbfd "tm: h_table.c", func=0x7fc3bf8ebed8 "free_cell",
>      line=162) at mem/f_malloc.c:588
> #3  0x00007fc3bf8300a1 in free_cell (dead_cell=0x7fc1b71da540) at
> h_table.c:162
> #4  0x00007fc3bf831705 in free_hash_table () at h_table.c:448
> #5  0x00007fc3bf85577a in tm_shutdown () at t_funcs.c:123
> #6  0x0000000000590d79 in destroy_modules () at sr_module.c:811
> #7  0x000000000049bb43 in cleanup (show_status=1) at main.c:569
> #8  0x000000000049d10b in shutdown_children (sig=15, show_status=1)
>      at main.c:711
> #9  0x000000000049f6e1 in handle_sigs () at main.c:802
> #10 0x00000000004a6fbf in main_loop () at main.c:1757
> #11 0x00000000004ab8bf in main (argc=11, argv=0x7fff1dbcda68) at
> main.c:2578
>
> The fact that shutdown handlers were called makes me wonder if this is
> not so much a crash as a foreseen condition that I am not properly
> handling, like OOM. Can anyone shed any light?
>
> Thanks,
>


-- 
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/