[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Mon Aug 6 12:39:53 CEST 2012


Tony please look at this further?

The error was that pthread_suspend_np ?or resume, I forget which, on FreeBSD was failing with 

#define    ESRCH        3        /* No such process */


which really shouldn't happen.


Index: src/thread/PTHREAD/ThreadPThread.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v
retrieving revision 1.261
diff -u -r1.261 ThreadPThread.m3
--- src/thread/PTHREAD/ThreadPThread.m3    6 Aug 2012 09:16:01 -0000    1.261
+++ src/thread/PTHREAD/ThreadPThread.m3    6 Aug 2012 10:33:27 -0000
@@ -421,11 +421,10 @@
 
     RunThread(me);
 
-    me.stackbase := NIL; (* disable GC scanning of my stack *)
-
     (* remove from the list of active threads *)
     WITH r = pthread_mutex_lock(activeMu) DO <*ASSERT r=0*> END;
       <*ASSERT allThreads # me*>
+      me.stackbase := NIL; (* disable GC scanning of my stack *)
       me.next.prev := me.prev;
       me.prev.next := me.next;
       WITH r = pthread_detach_self() DO <*ASSERT r=0*> END;





> Date: Mon, 6 Aug 2012 12:36:00 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	12/08/06 12:36:00
> 
> Modified files:
> 	cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 
> 
> Log message:
> 	me.stackbase := NIL inside activeMu, so that dying threads
> 	aren't suspended/resumed
> 	
> 	I tried making suspend/resume always succeed if stackbase = NIL,
> 	but that access violated in StopWorld; I don't understand.
> 	
> 	That is, setting it NIL outside the locks should be ok, as long
> 	as the code inside the locks notices.
> 	
> 	Test case if starting Juno on I386_FREEBSD with gcc 4.7 backend.
> 	It doesn't reproduce under a debugger.
> 	
> 	Note that probably FreeBSD, x86, gcc 4.7 aren't relevant.
> 	What probably is relevant is that Juno creates many threads
> 	and probably much garbage and heap allocations during startup.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20120806/6f3ca1ac/attachment-0002.html>


More information about the M3commit mailing list