[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Fri Sep 4 15:20:03 CEST 2009


Maybe it is merely 0?

This breaks things right away -- can't build the compiler, not related to Juno investigation.

 

 - Jay

 


CC: hosking at elego.de; m3commit at elegosoft.com
From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Subject: Re: [M3commit] CVS Update: cm3
Date: Fri, 4 Sep 2009 09:14:49 -0400

Umm.   That assertion should never fail.  I put it in to make sure we weren't totally broken in the threads system. (One should never have a negative thread.inCritical value, and that check makes sure the DEC on the next line is correct.







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 4 Sep 2009, at 06:01, Jay K wrote:

This breaks things badly.
I'm going to undo it.
 
***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1430
***
 
***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 2253
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x12f4a0   0x610eb4  LongAlloc + 0x7a in ..\src\runtime\common\RTCollector.m3
 0x12f4d8   0x610dd8  AllocTraced + 0x8a in ..\src\runtime\common\RTCollector.m3
 0x12f52c   0x60e7d7  Move + 0x2fc in ..\src\runtime\common\RTCollector.m3
 0x12f570   0x637731  Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3
.........  .........  ... more frames ...
 
 
 - Jay

 
> Date: Fri, 4 Sep 2009 05:32:52 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 09/09/04 05:32:51
> 
> Modified files:
> cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 
> cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 
> cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3 
> 
> Log message:
> Don't hack thread.inCritical unnecessarily. Just make sure this thread is not
> inCritical when acquiring/releasing the heap lock.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090904/f570a412/attachment-0002.html>


More information about the M3commit mailing list