[M3devel] @M3paranoidgc always crashes

[Olaf Wagner]

Quoting Tony Hosking <hosking at cs.purdue.edu>:

>  Jay may have fixed this for now.

It seems to be still broken, at least in the release branch. I'm currently
adding some tests. Running a simple test program with @M3paranoidgc
does not terminate:

% ../src/p2/p213/FreeBSD4/pgm
`Hello world' and `Hello world' are equal.
The length of the first is 11
Extracting four chars from position 3 yields --lo w--
Salut = Hello

done.
luthien [~/work/cm3/m3-sys/m3tests/src] wagner
% ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc


***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL^C

It only prints half of the message and eats lots of CPU afterwards.

I'll open a ticket for it and won't build release packages until it is
fixed.

Ticket is #1063.

Olaf

>
> On 20 Aug 2009, at 11:10, Olaf Wagner wrote:
>
>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>
>>> 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.
>>
>> Jay, could you open a ticket for that, too?
>>
>> And we also need to add tests for running with various @M3 options...
>>
>> Olaf
>>
>>>
>>> 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)
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194