[M3devel] @M3paranoidgc always crashes

[Tony Hosking]

Indeed, the use of paranoidgc itself now seems to be broken  
(independently of any other bug you might be trying to track down by  
invoking paranoidgc).
This is a serious bug, that should be rectified *before* any release.   
Without it, we cannot easily diagnose GC bugs in the field. I have  
little to no time to devote to this right now, but it does look like  
the recent changes to threading initialisation has broken things.  I  
remember being very careful about initialization of threads and heap  
components of the run-time when working on the original native  
threads.  In particular, the ability to invoke ThreadF.GetActivation  
was allowed before ThreadF.Init had been called, because  
ThreadF.InitActivations was able to be invoked on-demand independently  
of ThreadF.Init.  This independence now seems to have been eliminated  
so as to eliminate a run-time check in GetActivation.

On 20 Aug 2009, at 05:55, Jay K wrote:

>
> Verified on SOLgnu and AMD64_LINUX.
> Probably related to initialization order changes that let user  
> threads work again.
> Probably should just use untraced?
>
>
>
> % gdb --args ./cm3 @M3paranoidgc
> GNU gdb 6.4.90-debian
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and  
> you are
> welcome to change it and/or distribute copies of it under certain  
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for  
> details.
> This GDB was configured as "x86_64-linux-gnu"...Using host  
> libthread_db library
> "/lib/libthread_db.so.1".
> (gdb) run
> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc
> [Thread debugging using libthread_db enabled]
> [New Thread 47899659458256 (LWP 29607)]
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 47899659458256 (LWP 29607)]
> 0x00000000006934c5 in RTAllocator__GetTracedObj  
> (M3_Eic7CK_def=Cannot access mem
> ory at address 0x800028d97718
> )
>    at ../src/runtime/common/RTAllocator.m3:221
> 221         INC(thread.inCritical);
> (gdb) bt
> #0  0x00000000006934c5 in RTAllocator__GetTracedObj  
> (M3_Eic7CK_def=Cannot access
> memory at address 0x800028d97718
> )
>    at ../src/runtime/common/RTAllocator.m3:221
> #1  0x0000000000692e1f in RTHooks__AllocateTracedObj  
> (M3_AJWxb1_defn=Cannot acce
> ss memory at address 0x800028d97788
> )
>    at ../src/runtime/common/RTAllocator.m3:120
> #2  0x000000000069b3ae in RTCollector__InstallSanityCheck ()
>    at ../src/runtime/common/RTCollector.m3:1637
> #3  0x00000000006a1747 in RTHeapRep__Init ()
>    at ../src/runtime/common/RTCollector.m3:2769
> #4  0x00000000006a2a1d in RTLinker__InitRuntime  
> (M3_AcxOUs_p_argc=Cannot access
> memory at address 0x800028d97858
> )
>    at ../src/runtime/common/RTLinker.m3:58
> #5  0x00000000004160bc in main (argc=Cannot access memory at address  
> 0x800028d97
> 8a8
> ) at _m3main.mc:3
> (gdb)
>
>
>

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