Asterisk 13.6 - Program terminated with signal 6, Aborted (core dump)

Asterisk Asterisk Support
1

my asterisk is dying with a core dump (signal 6), I haven’t found the cause, could you please help?
Follows information of the core dump.

(gdb) bt
#0 0x00007fef96fcc4f5 in raise () from /lib64/libc.so.6
#1 0x00007fef96fcdcd5 in abort () from /lib64/libc.so.6
#2 0x00007fef96fc566e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007fef96fc5730 in __assert_fail () from /lib64/libc.so.6
#4 0x00000000004fcbc2 in fixed_jb_get (jb=, frame=, now=, interpl=)
at fixedjitterbuf.c:296
#5 0x0000000000432701 in jb_get_fixed (jb=, fout=0x7fede5ab2838, now=, interpl=)
at abstract_jb.c:664
#6 0x000000000043230e in hook_event_cb (chan=, frame=0x862660, event=, data=0x7fedf0025e60)
at abstract_jb.c:963
#7 0x00000000005043aa in framehook_list_push_event (framehooks=0x7fedf0010730, frame=0x862660, event=AST_FRAMEHOOK_EVENT_READ) at framehook.c:118
#8 0x00000000004b4036 in __ast_read (chan=0x7fef9003b038, dropaudio=0) at channel.c:3883
#9 0x0000000000476fcb in bridge_handle_trip (bridge_channel=0x7fef9003d288) at bridge_channel.c:2340
#10 bridge_channel_wait (bridge_channel=0x7fef9003d288) at bridge_channel.c:2510
#11 0x0000000000478048 in bridge_channel_internal_join (bridge_channel=0x7fef9003d288, cond=) at bridge_channel.c:2678
#12 0x0000000000467f87 in bridge_channel_ind_thread (data=0x7fede60fa980) at bridge.c:1620
#13 0x00000000005bf8be in dummy_start (data=) at utils.c:1237
#14 0x00007fef97ec7aa1 in start_thread () from /lib64/libpthread.so.0
#15 0x00007fef97082c4d in clone () from /lib64/libc.so.6
(gdb)

2

Your version of Asterisk is quite old (over 4 years old), so it is unlikely that anyone will invest the time to investigate a problem that may already be solved.

3

Thank you very much, but would you have an idea of what could be causing the problem and if this is already resolved in newer versions?

4

It’s an assertion in the jitterbuffer. You’d need to look at the specific source file and line number to determine which assertion. As for whether it is fixed or not, without looking through history I can’t answer that. I can say I don’t believe I’ve seen any such assertion or issue though.

5

Analyzing the occurrences, I found that it coincides with the update of the watch by ntp, but it does not occur every time.
I’m thinking of disabling ntp and performing the update only during low usage times.
Thanks.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.