<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Fix is in head.<br><br> - Jay<br><br>> Date: Fri, 21 Aug 2009 21:36:52 +0200<br>> From: wagner@elegosoft.com<br>> To: hosking@cs.purdue.edu; jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] @M3paranoidgc always crashes<br>> <br>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<br>> <br>> > Jay may have fixed this for now.<br>> <br>> It seems to be still broken, at least in the release branch. I'm currently<br>> adding some tests. Running a simple test program with @M3paranoidgc<br>> does not terminate:<br>> <br>> % ../src/p2/p213/FreeBSD4/pgm<br>> `Hello world' and `Hello world' are equal.<br>> The length of the first is 11<br>> Extracting four chars from position 3 yields --lo w--<br>> Salut = Hello<br>> <br>> done.<br>> luthien [~/work/cm3/m3-sys/m3tests/src] wagner<br>> % ../src/p2/p213/FreeBSD4/pgm @M3paranoidgc<br>> <br>> <br>> ***<br>> *** runtime error:<br>> *** Segmentation violation - possible attempt to dereference NIL^C<br>> <br>> It only prints half of the message and eats lots of CPU afterwards.<br>> <br>> I'll open a ticket for it and won't build release packages until it is<br>> fixed.<br>> <br>> Ticket is #1063.<br>> <br>> Olaf<br>> <br>> ><br>> > On 20 Aug 2009, at 11:10, Olaf Wagner wrote:<br>> ><br>> >> Quoting Tony Hosking <hosking@cs.purdue.edu>:<br>> >><br>> >>> Indeed, the use of paranoidgc itself now seems to be broken<br>> >>> (independently of any other bug you might be trying to track down by<br>> >>> invoking paranoidgc).<br>> >>> This is a serious bug, that should be rectified *before* any release.<br>> >>> Without it, we cannot easily diagnose GC bugs in the field. I have<br>> >>> little to no time to devote to this right now, but it does look like<br>> >>> the recent changes to threading initialisation has broken things. I<br>> >>> remember being very careful about initialization of threads and heap<br>> >>> components of the run-time when working on the original native<br>> >>> threads. In particular, the ability to invoke ThreadF.GetActivation<br>> >>> was allowed before ThreadF.Init had been called, because<br>> >>> ThreadF.InitActivations was able to be invoked on-demand independently<br>> >>> of ThreadF.Init. This independence now seems to have been eliminated<br>> >>> so as to eliminate a run-time check in GetActivation.<br>> >><br>> >> Jay, could you open a ticket for that, too?<br>> >><br>> >> And we also need to add tests for running with various @M3 options...<br>> >><br>> >> Olaf<br>> >><br>> >>><br>> >>> On 20 Aug 2009, at 05:55, Jay K wrote:<br>> >>><br>> >>>><br>> >>>> Verified on SOLgnu and AMD64_LINUX.<br>> >>>> Probably related to initialization order changes that let user <br>> >>>> threads work again.<br>> >>>> Probably should just use untraced?<br>> >>>><br>> >>>><br>> >>>><br>> >>>> % gdb --args ./cm3 @M3paranoidgc<br>> >>>> GNU gdb 6.4.90-debian<br>> >>>> Copyright (C) 2006 Free Software Foundation, Inc.<br>> >>>> GDB is free software, covered by the GNU General Public License, <br>> >>>> and you are<br>> >>>> welcome to change it and/or distribute copies of it under <br>> >>>> certain conditions.<br>> >>>> Type "show copying" to see the conditions.<br>> >>>> There is absolutely no warranty for GDB. Type "show warranty" <br>> >>>> for details.<br>> >>>> This GDB was configured as "x86_64-linux-gnu"...Using host <br>> >>>> libthread_db library<br>> >>>> "/lib/libthread_db.so.1".<br>> >>>> (gdb) run<br>> >>>> Starting program: /home/jkrell/cm3/bin/cm3 @M3paranoidgc<br>> >>>> [Thread debugging using libthread_db enabled]<br>> >>>> [New Thread 47899659458256 (LWP 29607)]<br>> >>>> Program received signal SIGSEGV, Segmentation fault.<br>> >>>> [Switching to Thread 47899659458256 (LWP 29607)]<br>> >>>> 0x00000000006934c5 in RTAllocator__GetTracedObj <br>> >>>> (M3_Eic7CK_def=Cannot access mem<br>> >>>> ory at address 0x800028d97718<br>> >>>> )<br>> >>>> at ../src/runtime/common/RTAllocator.m3:221<br>> >>>> 221 INC(thread.inCritical);<br>> >>>> (gdb) bt<br>> >>>> #0 0x00000000006934c5 in RTAllocator__GetTracedObj <br>> >>>> (M3_Eic7CK_def=Cannot access<br>> >>>> memory at address 0x800028d97718<br>> >>>> )<br>> >>>> at ../src/runtime/common/RTAllocator.m3:221<br>> >>>> #1 0x0000000000692e1f in RTHooks__AllocateTracedObj <br>> >>>> (M3_AJWxb1_defn=Cannot acce<br>> >>>> ss memory at address 0x800028d97788<br>> >>>> )<br>> >>>> at ../src/runtime/common/RTAllocator.m3:120<br>> >>>> #2 0x000000000069b3ae in RTCollector__InstallSanityCheck ()<br>> >>>> at ../src/runtime/common/RTCollector.m3:1637<br>> >>>> #3 0x00000000006a1747 in RTHeapRep__Init ()<br>> >>>> at ../src/runtime/common/RTCollector.m3:2769<br>> >>>> #4 0x00000000006a2a1d in RTLinker__InitRuntime <br>> >>>> (M3_AcxOUs_p_argc=Cannot access<br>> >>>> memory at address 0x800028d97858<br>> >>>> )<br>> >>>> at ../src/runtime/common/RTLinker.m3:58<br>> >>>> #5 0x00000000004160bc in main (argc=Cannot access memory at <br>> >>>> address 0x800028d97<br>> >>>> 8a8<br>> >>>> ) at _m3main.mc:3<br>> >>>> (gdb)<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br></body>
</html>