[M3devel] @M3paranoidgc always crashes

[Jay K]

Fix is in head.

 - 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090821/51ea577f/attachment-0002.html>