[OpenSIPS-Users] core dump in b2b

[Bogdan-Andrei Iancu]

Hi Jeff,

I got some lead on this, but I need to consult with Anca on the possible 
fix - she is the author of the code and I do not want to break things 
there :).

Regards,
Bogdan

PS: I guess you are using the latest SVN version, right ?


Jeff Pyle wrote:
> Hi Bogdan,
>
> This is the first time I've tried this.  Let me know if I need to run anything else.
>
> # gdb opensips core.32765
> [ opening dribble ... ]
>
> (gdb) print leg
> $1 = (dlg_leg_t *) 0xb4153838
> (gdb) print from_tag
> $2 = (str *) 0x0
> (gdb) print *leg
> $3 = {id = 0, tag = {s = 0xb4153860 "43fd11f70ee25a382597ac560865d088.ccac94.4\001", len = 37}, cseq = 103, 
>   route_set = {s = 0x0, len = 0}, contact = {s = 0x0, len = 0}, bind_addr = 0x81b820c, next = 0x0}
> (gdb) print *from_tag
> Cannot access memory at address 0x0
>
>
> - Jeff
>
>
>
> On May 18, 2010, at 12:49 PM, Bogdan-Andrei Iancu wrote:
>
>   
>> Hi Jeff,
>>
>> in frame 0, could you print "leg" , "from_tag" and "*leg", "*from_tag" ?
>>
>> Thanks and regards,
>> Bogdan
>>
>> Jeff Pyle wrote:
>>     
>>> Hello,
>>>
>>> I'm working through a top-hiding configuration from SVN.  I've got build 6877.  The configuration is very simple:  rewrite $rd with a value pulled from a custom header on the incoming request invite, and run b2b_init_request("top hiding").  The b2b_request and b2b_reply routes exist as well, only executing an xlog.
>>>
>>> The scenario appears to work correctly, unless the upstream proxy returns a 403 Forbidden.  The SIP traffic appears to flow properly (the 403s and the ACKs) but the top-hiding proxy immediately core dumps after it receives the ACK from the UAC.
>>>
>>> #0  0x006f7de0 in b2b_search_htable_dlg (table=0xb414b7d4, hash_index=366, local_index=7315224, to_tag=0xb41537f4, 
>>>    from_tag=0x0, callid=0xb41537e4) at dlg.c:100
>>> #1  0x006fcb8f in b2b_entity_delete (et=B2B_CLIENT, b2b_key=0xb4153750, dlginfo=0xb41537e4) at dlg.c:1039
>>> #2  0x00865248 in b2bl_delete (tuple=0xb4150270, hash_index=366) at records.c:199
>>> #3  0x00861e3b in b2b_logic_notify (src=0, msg=0x81bcf58, key=0xbfe894b8, type=0, param=0xbfe894b0) at logic.c:668
>>> #4  0x008639c4 in b2b_server_notify (msg=0x81bcf58, key=0xbfe894b8, type=0, param=0xbfe894b0) at logic.c:1199
>>> #5  0x006f9146 in b2b_prescript_f (msg=0x81bcf58, uparam=0x0) at dlg.c:583
>>> #6  0x080b535a in exec_pre_req_cb (msg=0x81bcf58) at script_cb.c:155
>>> #7  0x0809db74 in receive_msg (
>>>    buf=0x81922c0 "ACK sip:1111111111 at domain.com;user=phone SIP/2.0\r\nVia: SIP/2.0/UDP 5.4.3.2:5060;branch=z9hG4bK2dc67df9\r\nFrom: \"Jeff Pyle\" <sip:0000000000 at 5.4.3.2>;tag=as4ded813f\r\nTo: <sip:2"..., 
>>>    len=443, rcv_info=0xbfe89584) at receive.c:156
>>> #8  0x080e5306 in udp_rcv_loop () at udp_server.c:492
>>> #9  0x08070710 in main (argc=3, argv=0xbfe89784) at main.c:818
>>>
>>> Headers manually modified here to protect the guilty.
>>>
>>> I'm about to try the latest 1.6 build to see if it makes a difference.
>>>
>>>