Re: [reSIProcate-users] Crash after cancelling a Client Invite Session

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

This looks like a new bug, and from what I can see if the timing is right (ie: TimerCleanup fires before TimerD) this can happen with a 487 response too.  We we receive the 4xx response we transition to the Completed state, send an ACK and clear mNextTransmission.  So I think moving the log statement into the proceeding state check will fix this.  I'll commit this fix.

Thanks for the details report.

Scott

On Wed, Jul 17, 2013 at 10:26 AM, Thomas Troy <thomas.troy@xxxxxxxxxxxxxxxxxxxx> wrote:

Hi,

 

Sorry forgot to add that. We are using reciprocate v1.8.8 on RHEL 6.3

 

Thom

 

From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: 17 July 2013 15:18
To: Thomas Troy
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Crash after cancelling a Client Invite Session

 

Hi Thomas,

 

What version or revision of resip are you using?  I know we have addressed a few defects surrounding Cancel processing in the last few months.

 

Thanks,

Scott

On Tue, Jul 16, 2013 at 7:16 AM, Thomas Troy <thomas.troy@xxxxxxxxxxxxxxxxxxxx> wrote:

Hi,

 

We use reciprocate and dum as the sip stack for a B2BUA. We have recently noticed a problem that can cause a crash with the handling of the cleanup timer after cancelling a Client Invite Session.

 

The basic scenario is that

1)      We receive and forward an INVITE

2)      No OK is received and after a timeout we tell the stack to end the call.

3)      This causes a 480 to be sent to Leg1, and a CANCEL to Leg2.

4)      We never receive a 487 response that the CANCEL should have caused and instead receive a 408 Request Timeout after about 30 seconds.

5)      Then about 30 seconds later a cleanup timer is called in the stack and our application crashes.

 

I have attached a wireshark trace showing the call flow, the crash normally happens about 30 seconds after the 408 Request Timeout on the call to the 64 second cleanup timer.

 

Debugging the crash shows that it happens in TransactionState::processClientInvite line 1399, when trying to log the TimerCleanUp message

 

1399            StackLog (<< "Timer::TimerCleanUp: " << *this << std::endl << *mNextTransmission);

1400             if (mState == Proceeding)

1401             {

1402                assert(mNextTransmission && mNextTransmission->isRequest() &&

1403                         mNextTransmission->method() == INVITE);

 

It appears that mNextTransmission is NULL and the attempt to trace it causes a crash.

 

The stack trace shows

 

#0  0x082f7a33 in resip::operator<<(std::basic_ostream<char, std::char_traits<char> >&, resip::Message const&) ()

#1  0x08355efa in resip::TransactionState::processClientInvite(resip::TransactionMessage*) ()

#2  0x08353ad7 in resip::TransactionState::processTimer(resip::TransactionController&, resip::TimerMessage*) ()

#3  0x08348e32 in resip::TransactionController::process(int) ()

#4  0x08339e93 in resip::SipStack::processTimers() ()

#5  0x08339f77 in resip::SipStack::process(resip::FdSet&) ()

 

 

I’m not sure if this is a bug in reciprocate or if we are incorrectly handling the cancelling of the call and processing of the 408.

 

To work around the issue for now we have removed the trace line and there is no crash but any tips on resolving the issue would be appreciated.

 

Thom

 

 

 

 

 

Accuris Networks is a Private Limited Company registered in the Republic of Ireland.

Registered Number is 265266, with a registered office at O'Connell Bridge House, D'Olier St, Dublin 2.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/