Re: [reSIProcate-users] TransactionState crash
It's pretty tough with just the stack trace.
All I can really tell is that the 2nd crash is likely related to the deletion of mMsgToRetransmit in the TransactionState destructor. I suspect you've hit a code path that perhaps deletes this pointer, but does not set mMsgToRetransmit to NULL. I quickly reviewed the 1.2 version of TransactionState.cxx but I do not see any obvious errors surrounding mMsgToRetransmit. It's also possible to something else entirely is overwriting the memory used by this variable.
It would be good to see if you can reproduce the problem using SVN head, or 1.5 branch (soon to be released).
Scott
On Wed, Jun 10, 2009 at 6:03 AM, Krister Jarl
<kj@xxxxxxxxxxx> wrote:
Hi!
I've been experiencing some strange crashes.
#1 0x08307059 in resip::TransactionState::processClientStale
(this=0x45131f78, msg=0x45c787a8) at TransactionState.cxx:1282
#2 0x0830c023 in resip::TransactionState::process
(controller=@0x9fc55eec) at TransactionState.cxx:266
#3 0x082ffeda in resip::TransactionController::process
(this=0x9fc55eec, fdset=@0x9f2fe010) at TransactionController.cxx:83
#4 0x082f455f in resip::SipStack::process (this=0x9fc32368,
fdset=@0x9f2fe010) at SipStack.cxx:508
And:
#0 0x000003b9 in ?? ()
#1 0x082ef1d0 in ~SipMessage (this=0xca6a8b0) at SipMessage.cxx:172
#2 0x0830ab87 in ~TransactionState (this=0xa698d1c0) at
TransactionState.cxx:120
#3 0x08307059 in resip::TransactionState::processClientStale
(this=0xa698d1c0, msg=0xcf14ad0) at TransactionState.cxx:1282
#4 0x0830c023 in resip::TransactionState::process
(controller=@0xaa923b9c) at TransactionState.cxx:266
#5 0x082ffeda in resip::TransactionController::process
(this=0xaa923b9c, fdset=@0xa9ffe010) at TransactionController.cxx:83
#6 0x082f455f in resip::SipStack::process (this=0xaa900018,
fdset=@0xa9ffe010) at SipStack.cxx:508
I'm afraid I haven't got any reciprocate logs for you guys to look at,
but I hope the stack trace helps. The scenario for this to happen, at
least for the first trace, follows:
(from my UA's perspective)
INVITE -->
<-- 100
<-- 183
<-- 200
ACK -->
<-- BYE
--> 200
Crash
The crash occurs when TimerStaleClient fires, 32 s after 200 is
received.
I'm running reciprocate version 1.2 (yes, I know it's old :-))
Any ideas? Is there any way that I might be using the API wrong to get
this? I might add that this behaviour is not seen for all scenarios like
the above.
Regards,
Krister
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/