Re: [reSIProcate] Access Violation in Data.cxx

["Jeremy Geras" <jgeras@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxx]
Sent: Friday, November 17, 2006 1:12 PM
To: Jeremy Geras
Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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