[sr-dev] rtpengine crashes

[Richard Fuchs]

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