That should be fine then. So many bugs have been fixed since 1.2, that you might well have hit something that we've already fixed.
Best regards, Byron Campen I make a clone of the INVITE before sending it, which I keep. The SipMessages that I send down the stack are deleted as send() returns. Regars, Krister It is possible; are you holding onto a reference to the SipMessages you send down to the stack?
I’m attaching the message log, I hope that it might help a bit. I’ve tried reproducing the error with 1.2 but without any luck, so there’s not much point trying with 1.5. Is it possible that my app is misusing the stack in such a way that this would occur (other than simply writing in the wrong place)? Could you see such a scenario? 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). 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/ <resip.log>
|