Re: [reSIProcate] Access Violation in Data.cxx

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	Ok, let me clarify this statement; DUM is not threadsafe. However,  
the stack itself is (ie, you can have multiple stacks running at once  
in different threads. Also, you can have multiple TUs attached to a  
stack, each in their own thread, without problems). If you have run  
into thread-safety issues in the stack (as opposed to DUM), I would  
really like to know about them.

        Scott: Can you replicate this crash in basicCall?

Best regards,
Byron Campen

> 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 -
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature