[reSIProcate] Access Violation in Data.cxx

[Bruce Lowekamp]

This looks to me like the kind of bug I get whenever I accidentally
allow multithreaded use of resip. It's not threadsafe.  Others know
better what is supposed to work and what doesn't with the StackThread,
but I gave up getting it to work awhile ago and simple always call
process() directly on dum and stack, and make sure all of my accesses
to Dum are protected by a mutex.

Bruce

On 11/17/06, Jeremy  Geras <jgeras at newheights.com> wrote:
>
>
>
>
> OK, so a few other things I've learned:
>
>
>
> -          I can definitely reproduce this with basicCall (as is, latest
> code from SVN, with one minor modification to keep executing most of the
> main() in a loop).
>
> -          One way I've found to make the issue happen fairly quickly is to
> bog down the processor – e.g. I had this running for about 30 minutes on my
> 1.7GHz laptop with 384 MB of RAM, then went to try and open the Start Menu
> which made the machine chug away for a bit (likely since I had Visual Studio
> open), and bang, there was the exception.  I also experienced this yesterday
> on my workstation just after I connected to it using Remote Desktop (which
> also makes a machine chug away for a bit).  So there seems to be a
> correlation.  Might point to a timing issue?
>
> -          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.
>
>
>
> Very curious to know if anyone else can reproduce this, and if anyone has
> any thoughts on what the problem is?  As it is, the latest revision is
> unusable for me.
>
>
>
> Thanks,
>
>  - Jeremy -
>
>
>
>
>