[sr-dev] Remote-Party-ID Parsed Header Crash

[Joshua Colp]

On Sat, Jan 14, 2017, at 04:09 PM, Joshua Colp wrote:
> On Sat, Jan 14, 2017, at 02:43 PM, Joshua Colp wrote:
> 
> > 
> > Testing is in progress and so far so good. I do think the code in
> > acc_onreply that cleans up the parsed header is not correct, though.
> > It's referencing the shared memory memory instead of the locally scoped
> > one where any parsed headers (should) live.
> 
> 10,000 calls and zero problems. Going to push it further. I did try
> implementing the change to free the alloced headers on preq and it went
> very very poorly. Something still doesn't feel right with this over all,
> even with the fix.

Another crash occurred when freeing the Remote-Party-ID parsed value:

(gdb) bt
#0  0x000000000055adf6 in parse_addr_spec (buffer=0x7fff0d5d04a0
"\365?", end=0x7fff0d5d0410 "`8J\245\360\177", to_b=0x7fff0d5d04a0,
allow_comma_sep=32767)
    at parser/parse_addr_spec.c:912
#1  0x000000000055ae62 in free_to_params (tb=0x55ae62) at
parser/parse_addr_spec.c:921
#2  0x000000000054fde2 in clean_hdr_field (hf=0x7ff08e7e6248) at
parser/hf.c:142
#3  0x00007ff0a5274ec5 in acc_onreply (t=0x7ff08e902830,
req=0x7ff08e7e5230, reply=0x7ff0ac9f01a8, code=200) at acc_logic.c:511
#4  0x00007ff0a52753ec in tmcb_func (t=0x7ff08e902830, type=512,
ps=0x7fff0d5d0d40) at acc_logic.c:583
#5  0x00007ff0a746f478 in run_trans_callbacks_internal
(cb_lst=0x7ff08e9028a0, type=512, trans=0x7ff08e902830,
params=0x7fff0d5d0d40) at t_hooks.c:290
#6  0x00007ff0a746f68a in run_trans_callbacks_with_buf (type=512,
rbuf=0x7ff08e9028f0, req=0x7ff08e7e5230, repl=0x7ff0ac9f01a8, flags=200)
at t_hooks.c:336
#7  0x00007ff0a74a1c06 in relay_reply (t=0x7ff08e902830,
p_msg=0x7ff0ac9f01a8, branch=0, msg_status=200,
cancel_data=0x7fff0d5d10a0, do_put_on_wait=1)
    at t_reply.c:2001
#8  0x00007ff0a74a40b7 in reply_received (p_msg=0x7ff0ac9f01a8) at
t_reply.c:2499
#9  0x000000000045d837 in do_forward_reply (msg=0x7ff0ac9f01a8, mode=0)
at forward.c:777
#10 0x000000000045e0f8 in forward_reply (msg=0x7ff0ac9f01a8) at
forward.c:860
#11 0x00000000004a5887 in receive_msg (
    buf=0x9245e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
    128.177.41.40:5060;branch=z9hG4bK16.def8e32b85c1f9a00abfd00f56e513ff.0,
    SIP/2.0/UDP
    128.177.41.62:5061;rport=5061;branch=z9hG4bK-13531-8230-0\r\nFrom:
    sipp <sip:sipp at 128"..., len=603, rcv_info=0x7fff0d5d1420) at
    receive.c:273
#12 0x000000000053c838 in udp_rcv_loop () at udp_server.c:531
#13 0x000000000046d42b in main_loop () at main.c:1617
#14 0x00000000004704d3 in main (argc=11, argv=0x7fff0d5d1758) at
main.c:2533

(gdb) print *hf
$2 = {type = HDR_RPID_T, name = {
    s = 0x7ff08e7e5a54 "Remote-Party-ID: \"XXXXXXXXXX\"
    <sip:XXXXXXXXXX at XX.XXX.XXX.XXX>;party=calling;privacy=off;screen=no\r\nContact:
    sip:sipp at XXX.XXX.XX.XX:5061\r\nMax-Forwards: 69\r\nSubject:
    Performance Test\r\nContent-Type: appl"..., len = 15}, body = {
    s = 0x7ff08e7e5a65 "\"XXXXXXXXXX\"
    <sip:XXXXXXXXXX at XX.XXX.XXX.XXX>;party=calling;privacy=off;screen=no\r\nContact:
    sip:sipp at XXX.XXX.XX.XX:5061\r\nMax-Forwards: 69\r\nSubject:
    Performance Test\r\nContent-Type: application/sdp\r\nCont"..., len =
    80}, len = 99, parsed = 0x0, next = 0x7ff08e7e6288}

So it does indeed appear as though the change is incomplete. I'm going
to see if I can figure out an additional fix, and if there's any
additional information I can provide I'll try my best.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org