I found a crashed OpenSIPS process with the following backtrace:
~~~~
(gdb) bt
#0 tcp_read_req (con=con@entry=0xa773e948,
bytes_read=bytes_read@entry=0xbfb3b8cc) at tcp_read.c:711
#1 0x080e08a2 in handle_io (fm=0x99015c8, idx=idx@entry=-1,
event_type=event_type@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@entry=0x81e362c,
startup_done=startup_done@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
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
