[M3devel] @M3paranoidgc always crashes

[Olaf Wagner]

Quoting Jay K <jay.krell at cornell.edu>:

> Fix is in head.

OK. I merged runtime and thread from the trunk head. I couldn't
compile it though. Some imports were missing. Strange. With the
added imports, the tests seem to run fine.

Thanks,

Olaf

>  - Jay
>
>> Date: Fri, 21 Aug 2009 21:36:52 +0200
>> From: wagner at elegosoft.com
>> To: hosking at cs.purdue.edu; jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] @M3paranoidgc always crashes
>>
>> 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
>>
>



-- 
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