Re: [reSIProcate] Access Violation in Data.cxx
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@xxxxxxxxxxxxxx> 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 -