[M3devel] [M3commit] CVS Update: cm3

Sat Sep 12 11:26:51 CEST 2009

Tony,

 - You didn't like how I factored InitMutex and InitCondition via InitMutexHelper?

 - XWait doesn't have to initialize the mutex, because it must already

   be locked, and therefore initialized? Or is that a "safety hole"?

   Unsafe module trusting safe caller to have adhered to its interface

   but it might not have to so unsafe code has to do extra work to preserve safety?

   Reasonable to ASSERT instead? Or are asserts allowed to be removed

   and can't be used to guarantee safety?

   (I put them in C code used by Modula-3, but I can perhaps make the rules there.)

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sat, 12 Sep 2009 08:53:01 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30:

2009-02-16 02:30  hosking

  * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c,
    RTProcessPosixC.i3:

  Tidy up.

2009-02-16 02:20  hosking

  * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c,
    Csupport/little-endian/dtoa.c, convert/CConvert.i3,
    convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,
    runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,
    runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,
    thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,
    thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,
    thread/WIN32/ThreadWin32.m3:

  Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics.
  This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held.
  RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not.

2009-02-16 02:02  hosking

  * m3-libs/m3core/src/runtime/common/RTHeapMap.i3:

  Expose DoWalkRef.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Fri, 11 Sep 2009 22:21:44 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Hmmm.  Not sure.  Do you have the code diffs?

On 11 Sep 2009, at 17:28, Jay K wrote:

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 University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +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/20090912/8cb42996/attachment-0002.html>