[M3devel] [M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Fri Sep 11 23:28:43 CEST 2009


They aren't really in Trestle or ThreadWin32.
Well, right, often they are in ThreadWin32.
But not always.
I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't.
I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code.

I did narrow it down a 30 minute window.

 - Jay


From: hosking at cs.purdue.edu
To: rcoleburn at scires.com
Date: Fri, 11 Sep 2009 17:05:57 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation.  The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off.  It is inevitable with concurrent code that you will get different behavior at each run.  The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state.  Harder is actual crashes like you are observing.  If assertions can be used to monitor program invariants then it usually can be narrowed down.  Unfortunately, I am not in a position to debug the ThreadWin32 code.  Any help would be appreciated.  The question is whether the crashes you see are in Trestle or ThreadWin32.
 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 
On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony:   Will any of this make any difference on Windows platform?   I tried a couple of days ago to update all sources and rebuild.  Both Juno and Mentor still crash on both XP and Vista.  If you run multiple times, you get different crash results.  (So much for deterministic behavior.)  Let me know if there is anything I can do to help debug/test.   Regards, Randy

>>> Antony Hosking <hosking at elego.de> 9/11/2009 10:48 PM >>>
CVSROOT:/usr/cvs
Changes by:hosking at birch.09/09/11 22:48:37

Modified files:
cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 

Log message:
Mentor and Juno finally work on I386_DARWIN.
***Significant overhaul of thread alerting.***
Invariant now is that all waiting is done on the thread's own condition
variable.  This cleanly permits signals and alerts from any other thread.

Need  to set DISPLAY=:0.0 and xhost+ to get around problems with
DISPLAY=/tmp/launch-XXXXXX/:0.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090911/f3b3e355/attachment-0002.html>


More information about the M3devel mailing list