[reSIProcate] Access Violation in Data.cxx

[Jeremy Geras]

I'm curious if anyone else has had a chance to look at this yet?

 

In the meantime I've commented out the mMap.erase(i); in
TransactionMap::add(..) - that seems to do the trick, no more crashes.
I don't *think* it will leak without this line, but in any event Byron's
comments lead me to believe that perhaps there's a different/better
solution?

 

 - Jeremy -

 

________________________________

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Friday, November 17, 2006 1:12 PM
To: Jeremy Geras
Cc: Scott Godin; resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] Access Violation in Data.cxx

 

 

On Nov 17, 2006, at 1:12 PM, Jeremy Geras wrote:

-          The problem seems to be in TransactionMap::add(..) at the
point where it does mMap.erase(i).  The iterator appears to be invalid.
I have no idea why this might be the case, but I noticed something kinda
strange:  in TransactionMap::erase(..) there's a comment: "don't delete
it here, the TransactionState deletes itself and removes itself from the
map".  However in TransactionMap::add(..) it actually *does* delete the
TransactionState (delete i->second).  This is totally a guess, but
seemed strange to me.

You are correct, this code is broken. If, for some reason, we try to add
a TransactionState with the tid of an existing TransactionState, we end
up invalidating our iterator. (We end up calling erase() once in
~TransactionState(), and again immediately after.) However, I cannot see
how we could possibly end up in this code-path in the first place. We
either need to fix this code-path, or put an assert in its place (I
prefer this; this code-path is invalid in my opinion) Anyone have a
different opinion?

 

Best regards,

Byron Campen

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061127/37c4684e/attachment.htm>