On 06/27/14 14:35, Alex Balashov wrote:
I'm using the latest rtpengine master and still getting crashes once every 1-2 days on a high call volume installation:
(gdb) where #0 0x000000304e232925 in raise () from /lib64/libc.so.6 #1 0x000000304e234105 in abort () from /lib64/libc.so.6 #2 0x000000304e22ba4e in __assert_fail_base () from /lib64/libc.so.6 #3 0x000000304e22bb10 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000412d50 in stream_packet (fd=<value optimized out>, p= 0x7f1dcc1b1030, u=<value optimized out>) at call.c:547 #5 stream_fd_readable (fd=<value optimized out>, p=0x7f1dcc1b1030, u=<value optimized out>) at call.c:819 #6 0x000000000040b4ce in poller_poll (p=0x10d3750, timeout=<value optimized out>) at poller.c:354 #7 0x000000000040722d in poller_loop (d=0x10d3750) at main.c:542 #8 0x000000000040bb5f in thread_detach_func (d=<value optimized out>) at aux.c:160 #9 0x000000304e6079d1 in start_thread () from /lib64/libpthread.so.0 #10 0x000000304e2e8b6d in clone () from /lib64/libc.so.6
Unfortunately, this packet capture is not very insightful. What's the easiest way to build rtpengine with debug symbols so that some of these values can be filled in?
The easiest way would be to build it with "make debug", this should make everything visible.
But this backtrace is quite helpful already, as it's a deliberate assertion that triggers. If you're lucky, you can find the call-id through the "sfd" struct ("print sfd->call->callid.s"), and then check the logs to see what was going on. If that doesn't work, you can send me both the binary and the core, I may be able to get some details out of it.
cheers