27 Jun
2014
27 Jun
'14
11:41 p.m.
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