[M3devel] strange errors...
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Mon Jul 2 18:05:22 CEST 2007
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
More information about the M3devel
mailing list