Daniel-Constantin Mierla writes:

the module has support for async commands sent over HTTP, but not over other transport layers, iirc.

Good, I'll give it a try.

-- Juha

Get couple of more details from gdb:

frame 0

list

info locals

p *ctx

p *ctx->jreq

p *ctx->jrpl

Cheers, Daniel

On 17.08.18 14:14, Juha Heinanen wrote:

I cave tm.t_uac_wait over JSONRPC-S a try and got a crash:

(gdb) where #0 0x00007ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 #1 0x00007ff1ec5ee5ac in jsonrpc_delayed_ctx_close (dctx=0x7ff1e2706660) at jsonrpcs_mod.c:1037 #2 0x00007ff1f1deb375 in rpc_uac_callback (t=0x7ff1e26d91e0, type=1024, ps=0x7ffceb219720) at rpc_uac.c:391 #3 0x00007ff1f1e15d65 in run_trans_callbacks_internal (cb_lst=0x7ff1e26d9250, type=1024, trans=0x7ff1e26d91e0, params=0x7ffceb219720) at t_hooks.c:260 #4 0x00007ff1f1e15e89 in run_trans_callbacks (type=1024, trans=0x7ff1e26d91e0, req=0x0, rpl=0x7ff1f4b06130, code=200) at t_hooks.c:287 #5 0x00007ff1f1dca327 in local_reply (t=0x7ff1e26d91e0, p_msg=0x7ff1f4b06130, branch=0, msg_status=200, cancel_data=0x7ffceb2198f0) at t_reply.c:2136 #6 0x00007ff1f1dccb40 in reply_received (p_msg=0x7ff1f4b06130) at t_reply.c:2538 #7 0x0000560eda5a8744 in do_forward_reply (msg=0x7ff1f4b06130, mode=0) at core/forward.c:744 #8 0x0000560eda5aa18e in forward_reply (msg=0x7ff1f4b06130) at core/forward.c:845 #9 0x0000560eda6232ab in receive_msg ( buf=0x560edbc749a0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' <repeats 24 times>, ".0\r\nTo: sip:jh@test.tutpro.com;tag=skjao\r\nFrom: sip:click2dial@test.tutpro.com;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58) at core/receive.c:424 #10 0x0000560eda6c0ecd in receive_tcp_msg ( tcpbuf=0x7ff1e26d4038 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' <repeats 24 times>, ".0\r\nTo: sip:jh@test.tutpro.com;tag=skjao\r\nFrom: sip:click2dial@test.tutpro.com;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58, con=0x7ff1e26d3d40) at core/tcp_read.c:1428 #11 0x0000560eda6c319f in tcp_read_req (con=0x7ff1e26d3d40, bytes_read=0x7ffceb21a004, read_flags=0x7ffceb21a00c) at core/tcp_read.c:1611 #12 0x0000560eda6c6dc6 in handle_io (fm=0x7ff1f40b8690, events=1, idx=-1) at core/tcp_read.c:1843 #13 0x0000560eda6b41b7 in io_wait_loop_epoll (h=0x560edab49f40 <io_w>, t=2, repeat=0) at core/io_wait.h:1065 #14 0x0000560eda6c819c in tcp_receive_loop (unix_sock=45) at core/tcp_read.c:1955 #15 0x0000560eda56c056 in tcp_init_children () at core/tcp_main.c:4853 #16 0x0000560eda494912 in main_loop () at main.c:1711 #17 0x0000560eda49b92a in main (argc=17, argv=0x7ffceb21a688) at main.c:2645

-- Juha

I just pushed a commit in master branch, hopefully is fixing the issue -- let me know the results and if ok, it will be backported.

Cheers, Daniel

On 17.08.18 14:59, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

Get couple of more details from gdb:

Below, Juha

(gdb) frame 0 #0 0x00007ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 390 in jsonrpcs_mod.c (gdb) list 385 in jsonrpcs_mod.c (gdb) info locals nj = 0x0 i = -630111740 rbuf = {s = 0x3 <error: Cannot access memory at address 0x3>, len = -187033216} __func__ = "jsonrpc_send" (gdb) p *ctx $1 = {msg = 0x7ff1e270d170, msg_shm_block_size = 3024, method = 0x0, flags = 257, jreq = 0x0, req_node = 0x0, jrpl = 0x560edbc8ea20, rpl_node = 0x0, reply_sent = 1, error_code = 0, error_text = {s = 0x0, len = 0}, http_code = 200, http_text = {s = 0x7ff1ec607b1d "OK", len = 2}, transport = 1} (gdb) p *ctx->jreq Cannot access memory at address 0x0 (gdb) p *ctx->jrpl $2 = {root = 0x560edbc8f380, flags = 0, buf = {s = 0x0, len = 0}, malloc_fn = 0x7ff1f4ceef10 <__GI___libc_malloc>, free_fn = 0x7ff1f4cef510 <__GI___libc_free>}

On 18.08.18 19:16, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

I just pushed a commit in master branch, hopefully is fixing the issue -- let me know the results and if ok, it will be backported.

Daniel,

Thanks for the commit. My tm.t_uac_wait test (using master) now worked fine without issues.

Thanks for testing and reporting, I will backport.

Cheers, Daniel