[reSIProcate] repro crash with Jitsi
Scott Godin
sgodin at sipspectrum.com
Mon Jan 28 12:00:25 CST 2013
The assert is indicating a bug so it is valid.
After a quick look at the offending code, my guess is that we have received
a re-transmission of a non-invite request (ie PUBLISH) after we have formed
and sent our response, and we are supposed to be re-responding with the
same response as last time. However one of the code changes made in the
resip-b-TKLC-perf_work branch merge was to throw away the mNextTransmission
if it is a response. I suspect the purpose was to try and free up some
memory as soon as possible. However I see at least two places in the code
where re-transmitting a stored response is required.
1. Appears to be what you have found - Server Non-Invite transaction after
receiving a re-transmitted requested for which we have already responded.
2. When TimerG expires (Server Invite transaction) and we need to re
transmit an Invite response when we don't see the resulting ACK.
I am inclined to just comment out the code block starting on line 2567 in
order to fix this:
// !bwc! If mNextTransmission is a non-ACK request, we need to
save the
// initial request in case we need to send a simulated 408 or a
503 to
// the TU (at least, until we get a response back)
if(!mNextTransmission->isRequest() ||
mNextTransmission->method()==ACK)
{
delete mNextTransmission;
mNextTransmission=0;
}
However I'd like for Byron to chime in here, since these were originally
his changes.
Regards,
Scott
On Sun, Jan 27, 2013 at 4:44 PM, Daniel Pocock <daniel at pocock.com.au> wrote:
>
>
>
> I had heard about this in a private email, and have been `lucky' enough
> to observe it myself now, with a full log at STACK level too
>
> The UA (sip:1001 at srv1) is Jitsi v1.1.4400.10268 and repro is r9959 (main)
>
> The packet from Jitsi is below - has anyone seen similar issues with
> presence requests or Jitsi? Should the assert(0) be triggered there,
> does it actually indicate something is wrong, or should I just compile
> with NDEBUG and ignore it?
>
>
>
> The code in question is
>
> void
> TransactionState::sendCurrentToWire()
> {
> if(!mMsgToRetransmit.empty())
> {
> if(mController.mStack.statisticsManagerEnabled())
> {
> mController.mStatsManager.retransmitted(mCurrentMethodType,
> isClient(),
> mCurrentResponseCode);
> }
>
> mController.mTransportSelector.retransmit(mMsgToRetransmit);
> }
> else if(mNextTransmission) // initial transmission; need to determine
> target
> {
> ... snip ...
> }
> else
> { // line 2578
> assert(0);
> }
>
>
>
> DEBUG | 20130127-160854.896 | repro | RESIP:TRANSPORT | 140422323181312
> | ConnectionBase.cxx:418 | ##Connection: CONN_BASE: 0x7fb6a8234460 [ V4
> 192.168.1.100:49269 TLS target domain=unspecified mFlowKey=31 ]
> received: PUBLISH sip:1001 at srv1.office.readytechnology.co.uk SIP/2.0
> Via: SIP/2.0/TLS
> 192.168.1.100:49269;branch=z9hG4bK-373139-05d032d540e9bca18e3af732e0c948df
> Max-Forwards: 70
> Contact: "1001"
> <sip:1001 at 192.168.1.100:49269
> ;transport=tls;registering_acc=srv1_office_readytechnology_co_uk>
> To: "1001" <sip:1001 at srv1.office.readytechnology.co.uk>
> From: "1001" <sip:1001 at srv1.office.readytechnology.co.uk>;tag=c72de72a
> Call-ID: 9e82664c30f04d33d1ce879ab846a60b at 0:0:0:0:0:0:0:0
> CSeq: 2 PUBLISH
> Expires: 3600
> Content-Type: application/pidf+xml
> Proxy-Authorization: Digest
> username="1001",realm="srv1.office.readytechnology.co.uk
> ",nonce="1359299327:1ba2dffdf6697b06053efcfe4736f581",uri="
> sip:1001 at srv1.office.readytechnology.co.uk
> ",response="71efd5b4af3d25d2405c0e84d9c8e4eb",algorithm=MD5,qop=auth,cnonce="xyz",nc=00000001
> User-Agent: Jitsi1.1.4400.10268Windows 7
> Event: presence
> Content-Length: 452
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?><presence
> xmlns="urn:ietf:params:xml:ns:pidf"
> xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
> xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
> entity="sip:1001 at srv1.office.readytechnology.co.uk"><dm:person
> id="p556"><rpid:activities/></dm:person><tuple
> id="t6311"><status><basic>open</basic></status><contact>
> sip:1001 at srv1.office.readytechnology.co.uk
> </contact><note>Online</note></tuple></presence>
> DEBUG | 20130127-160854.896 | repro | RESIP:TRANSPORT | 140422323181312
> | Connection.cxx:298 | Connection::performReads() read=1352
> DEBUG | 20130127-160854.896 | repro | RESIP:TRANSPORT | 140422323181312
> | ConnectionBase.cxx:661 | Creating buffer for CONN_BASE: 0x7fb6a8234460
> [ V4 192.168.1.100:49269 TLS target domain=unspecified mFlowKey=31 ]
> STACK | 20130127-160854.896 | repro | RESIP:TRANSPORT | 140422323181312
> | ssl/TlsConnection.cxx:317 | SSL_read returned -1 bytes []
> STACK | 20130127-160854.896 | repro | RESIP:TRANSPORT | 140422323181312
> | ssl/TlsConnection.cxx:354 | Got TLS read got condition of 2
> STACK | 20130127-160854.896 | repro | RESIP:TRANSACTION |
> 140422331574016 | TransactionState.cxx:706 | Found matching transaction
> for SipReq: PUBLISH 1001 at srv1.office.readytechnology.co.uk
> tid=-373139-05d032d540e9bca18e3af732e0c948df cseq=2 PUBLISH
> contact=1001 at 192.168.1.100:49269 / 2 from(wire)
> tlsd=srv1.office.readytechnology.co.uk ->
> tid=-373139-05d032d540e9bca18e3af732e0c948df [
> ServerNonInvite/Proceeding reliable target=[ V4 192.168.1.100:49269 TLS
> target domain=unspecified mFlowKey=31 ]]
> STACK | 20130127-160854.896 | repro | RESIP:TRANSACTION |
> 140422331574016 | TransactionState.cxx:1438 |
> TransactionState::processServerNonInvite: SipReq: PUBLISH
> 1001 at srv1.office.readytechnology.co.uk
> tid=-373139-05d032d540e9bca18e3af732e0c948df cseq=2 PUBLISH
> contact=1001 at 192.168.1.100:49269 / 2 from(wire)
> tlsd=srv1.office.readytechnology.co.uk
> repro: TransactionState.cxx:2578: void
> resip::TransactionState::sendCurrentToWire(): Assertion `0' failed.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130128/ed16dba8/attachment.htm>
More information about the resiprocate-devel
mailing list