[OpenSIPS-Devel] [opensips] [1.11] Crash on TCP read (#813)

Saúl Ibarra Corretgé notifications at github.com
Mon Feb 29 13:09:55 CET 2016


I found a crashed OpenSIPS process with the following backtrace:

~~~~
(gdb) bt
#0  tcp_read_req (con=con at entry=0xa773e948, bytes_read=bytes_read at entry=0xbfb3b8cc) at tcp_read.c:711
#1  0x080e08a2 in handle_io (fm=0x99015c8, idx=idx at entry=-1, event_type=event_type at entry=1) at tcp_read.c:1036
#2  0x080e271c in io_wait_loop_epoll (repeat=<optimized out>, h=<optimized out>, t=<optimized out>)
    at io_wait.h:867
#3  tcp_receive_loop (unix_sock=72) at tcp_read.c:1144
#4  0x080dc690 in tcp_init_children (chd_rank=chd_rank at entry=0x81e362c, startup_done=startup_done at entry=0x0)
    at tcp_main.c:2378
#5  0x0805db02 in main_loop () at main.c:1011
#6  main (argc=11, argv=0xbfb3bbf4) at main.c:1612
~~~~

I inspected the code and found a path which leads to the problem. If the code entered [this if](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L704) `req` points to freed memory, so [this](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L711) causes the crash.

I think we need to jump to `end_req` right after freeing the request, but I'm not that familiar with the code to provide a patch.

Something does look a bit strange to me: if `size` was 0 (which is the case), then [this](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L678-L695) code path was followed, which means `release_tcpconn` was called. But when `tcp_read_req` returns (if it does so with an error) [this code](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L1036-L1045) will call `release_tcpconn` again.

As a side note, `release_tcpconn` shoudl probably set the `fd` attribute on the connection to -1 after closing it [here](https://github.com/OpenSIPS/opensips/blob/1.11/tcp_read.c#L451).

Unfortunately I cannot reproduce the issue, it's the first time I've seen it, and we've been running 1.11 in production on sip2sip.info for quite a while, always with async TCP enabled.

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/813
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20160229/72fab7c6/attachment.htm>


More information about the Devel mailing list