[M3devel] strange errors...

Mon Jul 2 21:50:44 CEST 2007

This problem has been fixed by the most recent update to  
RTCollector.m3, with respect to handling of weak references.

On Jul 2, 2007, at 12:05 PM, Daniel Alejandro Benavides D. wrote:

> Hi:
> In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the
> same problem is happensg, with the message of the
> RTCollector
>
> danielb at danielb-desktop:~$ mentor
>
>
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "../src/runtime/common/RTCollector.m3",
> line 2310
> ***
>
> Aborted
>
> danielb at danielb-desktop:~$
>
> With the @M3noincremental runs fine, @M3nogc also
> doesnt break.
>
>
>
> --- Tony Hosking <hosking at cs.purdue.edu> wrote:
>
>> Sigh, this is a knock-on bug that manifests as a
>> result of the
>> supposed "fix" I made in response to your previous
>> post.  As it turns
>> out, the user-level threads code has some badness
>> built in with
>> respect to incremental GC.  I need to rework the
>> user-level threading
>> code to totally eliminate use of traced references
>> in the code for
>> ProcessStacks.  The ring of threads needs to be
>> maintained in an
>> untraced data structure for the newer GC code to
>> work properly.  This
>> is something that is very carefully done in the
>> pthreads-based system-
>> level threading that is used on all the platforms I
>> typically
>> maintain locally (SOLgnu/SOLsun, LINUXLIBC6,
>> I386_DARWIN,
>> PPC_DARWIN), so I haven't seen this problem so
>> extensively.  You are
>> correct that running without incremental collection
>> (using
>> @M3noincremental) will avoid the problem until I am
>> able to come up
>> with a fix.
>>
>> On Jul 2, 2007, at 6:35 AM, Mika Nystrom wrote:
>>
>>> Ok, things are certainly better on FreeBSD/i386
>> now.  I just spent
>>> a few minutes playing a newly compiled tetris.
>>>
>>> However, I still get that very first error I wrote
>> about:
>>>
>>> /home/mika/u/parserlib/ktok/FreeBSD4/tok
>> ../src/Lang.t -o LangTok.i3
>>> WELCOME!
>>> GOT TOKPARAMS!
>>> GOT TOKENS
>>> GOT SUBS!
>>>
>>>
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file
>> "../src/runtime/common/RTCollector.m3", line 2310
>>> ***
>>>
>>> What I did was... I wasn't sure exactly what state
>> my CM3 was in,
>>> as usual, so I deleted all of /usr/local/cm3, plus
>> my repository
>>> checkout, checked it out from scratch, and
>> followed your bootstrap
>>> instructions of June 24 to the letter, except that
>> where you said
>>> to do "do-cm3-std.sh realclean" I did
>> "do-cm3-core.sh realclean"
>>> and then "do-cm3-std.sh realclean", built the
>> stage 1 and stage 2,
>>> installed the new compiler.  No problems until
>> trying to run
>>> this code, which is part of our local version of
>> the "caltech-
>>> parser"...
>>> Here we go:
>>>
>>>
>>> Program received signal SIGABRT, Aborted.
>>> 0x68b5e0c7 in kill () from /lib/libc.so.5
>>> (gdb) where
>>> #0  0x68b5e0c7 in kill () from /lib/libc.so.5
>>> #1  0x68b5312e in raise () from /lib/libc.so.5
>>> #2  0x68bc6cef in abort () from /lib/libc.so.5
>>> #3  0x682bc7f2 in RTOS__Crash () at RTOS.m3:20
>>> #4  0x682b3b66 in RTProcess__Crash
>> (M3_Bd56fi_msg=0x0) at
>>> RTProcess.m3:65
>>> #5  0x682b1e30 in RTError__EndError
>> (M3_AicXUJ_crash=1 '\001') at
>>> RTError.m3:115
>>> #6  0x682b1b71 in RTError__MsgS
>> (M3_AJWxb1_file=0x682dd4c8,
>>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0x682df048,
>>> M3_Bd56fi_msgB=0x682d9630,
>> M3_Bd56fi_msgC=0x682df048) at RTError.m3:40
>>> #7  0x682b21f4 in RTException__Crash
>> (M3_Cblw37_a=0xbfbfe0b8,
>>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x682d94e0)
>> at
>>> RTException.m3:79
>>> #8  0x682b1f58 in RTException__DefaultBackstop
>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0')
>> at RTException.m3:39
>>> #9  0x682b1ebc in RTException__InvokeBackstop
>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0')
>> at RTException.m3:25
>>> #10 0x682bdc37 in RTException__Raise
>> (M3_Cblw37_act=0xbfbfe0b8) at
>>> RTExFrame.m3:29
>>> #11 0x682b1ff8 in RTException__DefaultBackstop
>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0')
>> at RTException.m3:47
>>> #12 0x682b1ebc in RTException__InvokeBackstop
>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0')
>> at RTException.m3:25
>>> #13 0x682bdc37 in RTException__Raise
>> (M3_Cblw37_act=0xbfbfe0b8) at
>>> RTExFrame.m3:29
>>> #14 0x6829da9e in RTHooks__ReportFault
>>> (M3_AJWxb1_module=0x682dd640,
>> M3_AcxOUs_info=73920) at RTHooks.m3:110
>>> #15 0x682afc48 in _m3_fault (M3_AcxOUs_arg=73920)
>> from /usr/local/
>>> cm3/pkg/m3core/FreeBSD4/libm3core.so.5
>>> #16 0x682ad065 in RTHooks__CheckStoreTraced
>>> (M3_Af40ku_ref=0x68c2b104) at RTCollector.m3:2310
>>> #17 0x682bfba2 in ThreadPosix__LockMutex
>> (M3_AYIbX3_m=0x68c2b104)
>>> at ThreadPosix.m3:416
>>> #18 0x681ab817 in Wr__PutText
>> (M3_BxxOH1_wr=0x68c2b104,
>>> M3_Bd56fi_t=0x68c05608) at Wr.m3:93
>>> #19 0x0804a445 in Main_M3 (M3_AcxOUs_mode=1) at
>> Main.m3:113
>>> #20 0x682b120a in RTLinker__RunMainBody
>> (M3_DjPxE3_m=0x804cae0) at
>>> RTLinker.m3:399
>>> #21 0x682b0735 in RTLinker__AddUnitI
>> (M3_DjPxE3_m=0x804cae0) at
>>> RTLinker.m3:113
>>> #22 0x682b07bc in RTLinker__AddUnit
>> (M3_DjPxE5_b=0x8049e50) at
>>> RTLinker.m3:122
>>> #23 0x080491f5 in main (argc=4, argv=0xbfbfe40c,
>> envp=0xbfbfe420)
>>> at _m3main.mc:4
>>> (gdb)
>>>
>>>    2302 PROCEDURE CheckStoreTraced (ref: REFANY) =
>>>    2303   VAR p := Word.RightShift (LOOPHOLE(ref,
>> Word.T),
>>> LogBytesPerPage);
>>>    2304   BEGIN
>>>    2305     RTOS.LockHeap ();
>>>    2306     INC(checkStoreTraced);
>>>    2307
>>>    2308     WITH h = HeaderOf (LOOPHOLE(ref,
>> RefReferent)) DO
>>>    2309       <*ASSERT h.typecode #
>> RT0.TextLitTypecode*>
>>>    2310       <*ASSERT NOT h.gray*>
>>>    2311
>>>    2312       IF h.dirty THEN
>>>    2313         <*ASSERT NOT desc[p - p0].clean*>
>>>    2314       ELSE
>>>    2315         h.dirty := TRUE;
>>>    2316         IF desc[p - p0].clean THEN
>>>    2317           desc[p - p0].clean := FALSE;
>>>    2318           IF perfOn THEN PerfChange(p,
>> PageCount(p)); END;
>>>    2319         END;
>>>    2320       END;
>>>    2321     END;
>>>    2322
>>>    2323     RTOS.UnlockHeap();
>>>    2324     RETURN;
>>>    2325   END CheckStoreTraced;
>>>
>>> I believe this is the same as the first bug I ran
>> across.  The program
>>> (ktok) does appear to work fine with @M3nogc.
>>>
>>> Further information: I am also "able" to get
>> mentor and Juno to
>>> crash on this line 2310.  I checked the
>> bootstrapping process by
>>> building a third-stage bootstrapped compiler, and
>> it was byte-for-byte
>>> identical to the second-stage bootstrap.  Finally,
>> I am still a bit
>>> worried about libraries (maybe across the
>> different booting stages)
>>> getting polluted: I am able to run Juno, mentor,
>> etc., except for
>>> the garbage-collection problem, but my own Trestle
>> applications
>>> crash somewhere in the (C) X libraries, even
>> though they have worked
>>> fine on several other versions of Modula-3.  (Most
>> likely, of course,
>>> it's some sort of bug of mine... generally I am
>> not in the habit of
>>> blaming the libraries or compiler, but you never
>> know!)
>>>
>>> The line-2310 crashes also seem to go away with
>> @M3noincremental,
> === message truncated ===
>
>
>
> 		
> ______________________________________________
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com