[reSIProcate] Access Violation in Data.cxx

[Byron Campen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061117/eb3a7121/attachment.bin>