[M3devel] pthreads issues [was: Re: strange errors... ]
Mika Nystrom
mika at async.caltech.edu
Mon Jul 16 21:33:53 CEST 2007
You know, I live in constant fear of messing up the bootstrapping
every time that I CVS update, but yes, I am using the CVS sources.
My approach is to delete everything, and follow your instructions
of June 24 for bootstrapping. It takes a couple of hours each time
on my PowerBook.
Just to clarify some points:
1. The thread problems I've been seeing are on Darwin-PPC, OS X
10.3. The little testing program I showed doesn't fail on that
system. It just runs very, very slowly compared to user-level
threading. That particular program shows no signs, unfortunately,
of misbehavior. Actually, not much else really "fails" outright.
The programs just take 100% of the CPU, unless you pass them @M3nogc.
2. I modified ThreadPThread a bit because the debugger was not
helpful. Also you can't print with normal routines from ThreadPThread
so I use the low-level ones you see in the code snippet. The assertion
that fails on line 756 is something I added. If I change ThreadPThread
thus, then even mentor crashes on that assertion.
3. I am pretty sure this code comes from the CVS head, because the
code I started with was version 1.33, which appears to be what is
at the CVS head right now. The fact that the assertion fails
strongly suggests to me that I am using my own m3core, since the
assertion doesn't exist in the original sources (either the release
or the CVS head)! A corollary of that is that my bootstrapping
must have succeeded, at least as far as the ThreadPThread module is
concerned. Is there a better way to make sure? Actually, I think that
if you do do-cm3-core.sh realclean and do-cm3-std.sh realclean you do
get an absolutely clean repository. I think that because after I did
it once I went looking for PPC_DARWIN directories, and there were none,
or at most something with system-specific sources that was there before
I started.
Mika
Tony Hosking writes:
>All of these problems sound like things that were fixed since the
>last CM3 release. Are you using the "release" of CM3 or the CVS
>sources?
>
>On Jul 16, 2007, at 2:27 AM, Mika Nystrom wrote:
>
>> An update:
>>
>> I was able to get everything to build by using @M3noincremental.
>>
>> I am still running into a few errors when trying to run things.
>> So far, most problems seem to be traceable back to a garbage
>> collection
>> problem. @M3noincremental helps, but doesn't solve all GC-related
>> issues.
>
>> The errors I seem to be running into are...
>>
>> 1. Some kind of memory protection error when I am reading pickles
>> from files. Haven't looked at this in detail yet.
>> 2. The assert when spawning threads in mentor, mentioned earlier.
>> 3. Various sinks of processor time when running multithreaded things.
>>
>> The program I sent earlier to illustrate the (in)efficiency of
>> threading was an attempt to isolate some of the issues under 3., but
>> that simple program didn't seem to tickle any bugs. Instead, I have
>> an Othello program that does. It uses Trestle, X, etc., and you can
>> get it (via the references on the Wikipedia m3 page, actually: it
>> was originally part of an assignment for a class I was teaching at
>> Caltech).
>>
>> What happens is this... everything seems functionally correct, but
>> after a while, the program, for no apparent reason at all, starts
>> to take 100% of the CPU. I think there may be several bugs. I have
>> been able to get programs to slow down and threads to stop running.
>>
>> To the description: my othello program opens up a VBT and calls a
>> Thread.Join. This puts it in ThreadPThread.InnerWait, and there
>> all seems OK. The running thread (or one of them) calls Trestle.Ping,
>> which calls Thread.Pause. For a few seconds all is OK, the mouse
>> pointer is tracked, repaints work, etc. But after a while, the
>> program goes haywire. What happens is that the program is still
>> functionally correct, as before, but it starts to eat 100% CPU.
>> Looking a little closer, Thread.Pause has died, or is at least badly
>> wounded. It simply doesn't yield the CPU.
>>
>> I changed ThreadPThread.Pause to the following:
>>
>> PROCEDURE Pause(n: LONGREAL) =
>> VAR
>> amount, remaining: Utime.struct_timespec;
>> self := Self();
>> BEGIN
>> IF self = NIL THEN Die(ThisLine(), "Pause called from a non-
>> Modula-3 thread") END;
>> IF n <= 0.0d0 THEN RETURN END;
>> IF perfOn THEN PerfChanged(self.id, State.pausing) END;
>> ToNTime(n, amount);
>> <* ASSERT amount.tv_sec >= 0 *>
>>
>> RTIO.PutChar('f'); RTIO.Flush();
>> LOOP
>> RTIO.PutChar('b'); RTIO.Flush();
>> <* ASSERT amount.tv_sec >= 0 *> (* line 756 *)
>> RTIO.PutChar('a'); RTIO.Flush();
>> WITH nr = Utime.nanosleep(amount, remaining) DO
>> IF nr = 0 THEN
>> RTIO.PutChar('!'); RTIO.Flush();
>> EXIT
>> ELSE
>> RTIO.PutChar('.'); RTIO.Flush();
>> VAR
>> as := amount.tv_sec;
>> an := amount.tv_nsec;
>> rs := remaining.tv_sec;
>> rn := remaining.tv_nsec;
>> BEGIN
>> amount := remaining;
>> END
>> END
>> END
>> END;
>> IF perfOn THEN PerfChanged(self.id, State.alive) END;
>> END Pause;
>>
>> Ironically, the change seems to make the program slightly
>> less susceptible to trouble, but it still happens. The end result of
>> running my program is not terribly helpful:
>>
>> Repaint!
>> .ba.b
>>
>> ***
>> *** runtime error:
>> *** <*ASSERT*> failed.
>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 756
>> ***
>>
>>
>> Program exited with code 01.
>> (gdb) where
>> No stack.
>>
>> Note that line 756 is after the arguments to nanosleep have already
>> been checked. The tv_secs gets set to -1... and nanosleep returns
>> right away. But nanosleep declares its first argument as const *,
>> so it's not nanosleep itself that's clobbering it.
>>
>> XXX
>> XXX The problem goes away with @M3nogc. This problem does NOT
>> XXX go away with @M3noincremental!
>> XXX
>>
>> (And @M3paranoidgc doesn't seem to be any more paranoid than the
>> usual one.)
>>
>> Maybe this is a stupid question... why are Pause and AlertPause
>> implemented with different system calls? (Note that I had another
>> program that was exhibiting the same type of processor greed, and
>> changing all occurrences of Pause to AlertPause in that program
>> didn't seem to cure it.)
>>
>> I think mentor and Juno show the 100% CPU symptoms as well. Yes,
>> I just re-ran mentor and I got the same assertion failing.
>>
>> ----
>>
>> One last issue: there is indeed one more problem. @M3nogc does
>> solve the cpu utilization and Utime problems. It does not, however,
>> solve the protection bug (#1 above). Something's up, because Network
>> Objects do work fine, but reading and writing certain things to
>> disk does not appear to work (and those pickles were written by the
>> same executable as the one that tried to read them). All these
>> programs work reliably under PM3 on both FreeBSD and Windows
>> 2000/cygwin (not that I am suggesting that they are bug free).
>>
>> Mika
>>
>>
>> Tony Hosking writes:
>>>
>>> On Jul 15, 2007, at 9:53 PM, Mika Nystrom wrote:
>>>
>>>> Hello there,
>>>>
>>>> I am now back to trying to get my system compiled under CM3. Not
>>>> to pick on CM3 or anything, but my old PM3s still have no trouble
>>>> with it!
>>>
>>> PS Old PM3s don't have the new compiler-driven incremental
>>> collection scheme, so you will hopefully gain fromm moving to CM3 so
>>> long as we can fix your problem. I should be able to diagnose this
>>> without too much trouble. Any chance you can run with the
>>> @M3paranoidgc flag passed to tok?
>>>
>>>>
>>>> I'm back to staring at the following:
>>>>
>>>> ***
>>>> *** runtime error:
>>>> *** <*ASSERT*> failed.
>>>> *** file "../src/runtime/common/RTCollector.m3", line 2310
>>>> ***
>>>>
>>>> Here's how I got it: I ran the "tok" program from my example on one
>>>> of the example files (not sure if this is part of the distributed
>>>> "caltech-parser" or not). The revision of RTCollector.m3 is 1.29.
>>>>
>>>> I spoke to the author of "tok" last week (who now programs in a
>>>> kind of bastardized C++ with Modula-3 keywords and a garbage
>>>> collector), and he said this program actually does very little work.
>>>> It's just an interface generator that makes interfaces to declare
>>>> a few constants. Why it seems to have so much trouble running is
>>>> a mystery to me.
>>>>
>>>> traceback:
>>>>
>>>> (gdb) where
>>>> #0 0x9004308c in kill ()
>>>> #1 0x9009fb3c in abort ()
>>>> #2 0x00096f48 in RTOS__Crash () at RTOS.m3:20
>>>> #3 0x0005bcd8 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at
>>>> RTProcess.m3:65
>>>> #4 0x0008e4d8 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at
>>>> RTError.m3:115
>>>> #5 0x0008e084 in RTError__MsgS (M3_AJWxb1_file=0xc6420,
>>>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0xca418,
>>>> M3_Bd56fi_msgB=0xcbed8, M3_Bd56fi_msgC=0xca418) at RTError.m3:40
>>>> #6 0x0008eb80 in RTException__Crash (M3_Cblw37_a=0xbfffee20,
>>>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0xcb580) at RTException.m3:79
>>>> #7 0x0008e744 in RTException__DefaultBackstop
>>>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at
>>>> RTException.m3:39
>>>> #8 0x0008e60c in RTException__InvokeBackstop
>>>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at
>>>> RTException.m3:25
>>>> #9 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at
>>>> RTExFrame.m3:29
>>>> #10 0x0008e838 in RTException__DefaultBackstop
>>>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at
>>>> RTException.m3:47
>>>> #11 0x0008e60c in RTException__InvokeBackstop
>>>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at
>>>> RTException.m3:25
>>>> #12 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at
>>>> RTExFrame.m3:29
>>>> #13 0x00079738 in RTHooks__ReportFault (M3_AJWxb1_module=0xb3ec0,
>>>> M3_AcxOUs_info=73920) at RTHooks.m3:110
>>>> #14 0x0006ff44 in _m3_fault (M3_AcxOUs_arg=73920)
>>>> #15 0x0006bcec in RTHooks__CheckStoreTraced
>>>> (M3_Af40ku_ref=0xb24368) at RTCollector.m3:2310
>>>> #16 0x000700dc in ThreadPThread__InnerLockMutex
>>>> (M3_AYIbX3_m=0xb24368, M3_BXP32l_self=0xb244b0) at
>>>> ThreadPThread.m3:126
>>>> #17 0x000704d0 in ThreadPThread__LockMutex (M3_AYIbX3_m=0xb24368)
>>>> at ThreadPThread.m3:153
>>>> #18 0x00019abc in Wr__PutText (M3_BxxOH1_wr=0xb24368,
>>>> M3_Bd56fi_t=0xb403d4) at Wr.m3:93
>>>> #19 0x00003e94 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113
>>>> #20 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at
>>>> RTLinker.m3:399
>>>> #21 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at
>>>> RTLinker.m3:113
>>>> #22 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at
>>>> RTLinker.m3:122
>>>> #23 0x00001ecc in main (argc=4, argv=0xbffffb30, envp=0xbffffb44)
>>>> at _m3main.mc:4
>>>> (gdb)
>>>>
>>>> Line 113 in Main.m3 is:
>>>>
>>>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3")));
>>>>
>>>> (Bundle is made by m3bundle)
>>>>
>>>> OS:
>>>> Darwin lapdog.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
>>>> Macintosh powerpc
>>>>
>>>> This is a CM3 checkout from yesterday, built cleanly according to
>>>> your instructions (starting with an absolutely clean system and
>>>> bootstrapped using binary version 5.4.0). I managed to screw it
>>>> up at one point but I ran do-cm3-std realclean and do-cm3-core
>>>> realclean several times.
>>>>
>>>> But isn't this the bug you already fixed? I just don't see how I
>>>> could possibly be getting an old RTCollector.m3 file in my system.
>>>> I cleaned it obsessively while I was building it.
>>>>
>>>> I am using the cfg file you sent me, too. (I copied it in, in place
>>>> of the 5.4.0 default cfg.) You can see I am using pthreads.
>>>>
>>>> @M3noincremental and @M3nogc work, as usual.
>>>>
>>>> ----------
>>>>
>>>> I saw another problem. I was running mentor, the packet routing
>>>> animation, and hit an assertion in ThreadPThread.m3.
>>>>
>>>>
>>>> [lapdog:~] mika% mentor
>>>>
>>>>
>>>> ***
>>>> *** runtime error:
>>>> *** <*ASSERT*> failed.
>>>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 673
>>>> ***
>>>>
>>>> Abort
>>>>
>>>> WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*>
>>>> END;
>>>> WITH r = Upthread.attr_init(attr) DO <*ASSERT r=0*> END;
>>>> WITH r = Upthread.attr_getstacksize(attr, bytes) DO
>>>> <*ASSERT r=0*> END;
>>>> bytes := MAX(bytes, size * ADRSIZE(Word.T));
>>>> WITH r = Upthread.attr_setstacksize(attr, bytes) DO
>>>> <*ASSERT r=0*> END; (* line 673 *)
>>>> WITH r = Upthread.create(act.handle, attr, ThreadBase,
>>>> act) DO
>>>> <*ASSERT r=0*>
>>>> END;
>>>> act.next := allThreads;
>>>> act.prev := allThreads.prev;
>>>> act.size := size;
>>>> allThreads.prev.next := act;
>>>> allThreads.prev := act;
>>>> WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*>
>>>> END;
>>>> END;
>>>>
>>>> Is it trying to make too many threads? Is there a practical limit
>>>> on the number of threads under pthreads? (The code I am eventually
>>>> going to want to build will want to make hundreds and possibly
>>>> thousands of concurrently executing threads, which I don't think
>>>> is a problem with ThreadPosix, and I'll be pretty disappointed if
>>>> that turns out to be a problem with pthreads...well I suppose I can
>>>> always go back to user-level threads.)
>>>>
>>>> Mika
>>>>
>>>>
>>>> Tony Hosking writes:
>>>>> 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,
>>>>>> by the
>>>>>> way.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mika
>>>>>>
>>>>>> Tony Hosking writes:
>>>>>>> I've just checked in a fix to ThreadPosix.m3 that eliminates your
>>>>>>> problem with user-level threads. I have tested this on
>>>>>>> I386_DARWIN
>>>>>>> and it appears to be working just fine now. Please try again
>>>>>>> with
>>>>>>> the updated ThreadPosix.m3.
>>>>>>>
>>>>>>> On Jun 25, 2007, at 3:05 PM, Mika Nystrom wrote:
>>>>>>>
>>>>>>>> Indeed, -g was one of the culprits. I changed it to -gstabs+
>>>>>>>> and
>>>>>>>> got a bit further... (please scroll down to STEP 2, sorry)
>>>>>>>>
>>>>>>>> Tony Hosking writes:
>>>>>>>>> Sounds like we really need some work done in this area. I very
>>>>>>>>> rarely use the build scripts, since I bootstrap manually
>>>>>>>>> from old
>>>>>>>>> compilers to new compilers rather than use the scripts. I
>>>>>>>>> suggest
>>>>>>>>> the following approach, which I hope you will try, and then
>>>>>>>>> report
>>>>>>>>> back on.
>>>>>>>>>
>>>>>>>>> Install the bootstrap compiler as you did originally:
>>>>>>>>>
>>>>>>>>>> rm -rf /usr/local/cm3/*
>>>>>>>>>>
>>>>>>>>>> cd ~/cm3-cvs
>>>>>>>>>> mkdir boot
>>>>>>>>>> cd boot
>>>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz
>>>>>>>>>> ./cminstall
>>>>>>>>>
>>>>>>>>> Now you will have some kind of cm3 installed, presumably in /
>>>>>>>>> usr/
>>>>>>>>> local/cm3/bin/cm3.
>>>>>>>>>
>>>>>>>>> Make sure you have a fresh CVS checkout in directory cm3 (let's
>>>>>>>>> assume this is in your home directory ~/cm3). Also, make sure
>>>>>>>>> you
>>>>>>>>> have an up-to-date version of the CM3 backend compiler cm3cg
>>>>>>>>> installed by executing the following:
>>>>>>>>>
>>>>>>>>> STEP 0:
>>>>>>>>>
>>>>>>>>> export CM3=/usr/local/cm3/bin/cm3
>>>>>>>>> cd ~/cm3/m3-sys/m3cc
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>>
>>>>>>>>> You can skip this last step if you know your backend compiler
>>>>>>>>> is up
>>>>>>>>> to date.
>>>>>>>>>
>>>>>>>>> Now, let's build the new compiler from scratch (this is the
>>>>>>>>> sequence
>>>>>>>>> I use regularly to test changes to the run-time system
>>>>>>>>> whenever I
>>>>>>>>> make them):
>>>>>>>>>
>>>>>>>>> STEP 1:
>>>>>>>>>
>>>>>>>>> cd ~/cm3/m3-libs/m3core
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>> cd ~/cm3/m3-libs/libm3
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>> cd ~/cm3/m3-sys/m3middle
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>> cd ~/cm3/m3-sys/m3linker
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>> cd ~/cm3/m3-sys/m3front
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>> cd ~/cm3/m3-sys/m3quake
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>> cd ~/cm3/m3-sys/cm3
>>>>>>>>> $CM3
>>>>>>>>> $CM3 -ship
>>>>>>>>>
>>>>>>>>> At this point you should have a bootstrapped version of cm3
>>>>>>>>> installed
>>>>>>>>> in the directory /usr/local/cm3/pkg/cm3/TARGET/cm3 (where
>>>>>>>>> TARGET is
>>>>>>>>> the CM3 target platform you are building on -- e.g.,
>>>>>>>>> LINUXLIBC6,
>>>>>>>>> PPC_DARWIN, ...). Note that this did not overwrite your
>>>>>>>>> original
>>>>>>>>> installed compiler in /usr/local/cm3/bin/cm3. We
>>>>>>>>> are now going to test the new compiler, which was built using
>>>>>>>>> the old
>>>>>>>>> compiler, by bootstrapping it one more time.
>>>>>>>>>
>>>>>>>>> From here on out, please replace TARGET with your target
>>>>>>>>> platform as
>>>>>>>>> appropriate.
>>>>>>>>>
>>>>>>>>> STEP 2:
>>>>>>>>>
>>>>>>>>> export CM3=/usr/local/cm3/pkg/cm3/TARGET/cm3
>>>>>>>>> cd ~/cm3/scripts
>>>>>>>>> ./do-cm3-std.sh realclean
>>>>>>>>> REPEAT STEP 1 to rebuild the libraries and the compiler
>>>>>>>>> using the
>>>>>>>>> STEP 1 bootstrap compiler.
>>>>>>>>>
>>>>>>>>> Now you have a STEP 2 bootstrap compiler installed in /usr/
>>>>>>>>> local/
>>>>>>>>> cm3/
>>>>>>>>> pkg/cm3/TARGET/cm3. Let's assume the new compiler now works
>>>>>>>>> properly
>>>>>>>>> since it successfully bootstrapped itself, but to be sure we
>>>>>>>>> can
>>>>>>>>> now
>>>>>>>>> use it to rebuild the world:
>>>>>>>>
>>>>>>>> Ok, I got this far. I built the step 1 (m3core...cm3), set my
>>>>>>>> compiler to the newly-built compiler, and rebuilt
>>>>>>>> (m3core...cm3).
>>>>>>>> No errors anywhere, beautiful.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> cd ~/cm3/scripts
>>>>>>>>> ./do-cm3-std.sh realclean
>>>>>>>>> ./do-cm3-std.sh buildship
>>>>>>>>
>>>>>>>> Here's where it dies:
>>>>>>>>
>>>>>>>> ./do-cm3-std.sh buildship
>>>>>>>> CM3C =
>>>>>>>> /big/home2/mika/2/cm3-cvs/fresh/cm3/scripts/pkgmap.sh -c "/usr/
>>>>>>>> local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/home2/
>>>>>>>> mika/2/
>>>>>>>> cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 -
>>>>>>>> ship -
>>>>>>>> DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' " m3core libm3
>>>>>>>> patternmatching m3middle m3quake m3scanner m3tools m3cgcat
>>>>>>>> m3cggen
>>>>>>>> m3gdb m3bundle arithmetic bitvector digraph parseparams
>>>>>>>> realgeometry set slisp sortedtableextras table-list tempfiles
>>>>>>>> tcp
>>>>>>>> udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO
>>>>>>>> commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser
>>>>>>>> cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr
>>>>>>>> sharedobj sharedobjgen odbc postgres95 db smalldb stable
>>>>>>>> stablegen
>>>>>>>> X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps
>>>>>>>> formsvbt formsview formsedit codeview mg mgkit opengl anim3D
>>>>>>>> zeus
>>>>>>>> m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq
>>>>>>>> obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd
>>>>>>>> obliqsrvui obliqbinmin obliqbinstd obliqbin!
>>>>>>>> ui obliqbinanim visualobliq vocgi voquery vorun webvbt
>>>>>>>> recordheap
>>>>>>>> rehearsecode replayheap showheap shownew showthread pkl-fonts
>>>>>>>> juno-
>>>>>>>> machine juno-compiler juno-app cube calculator fisheye mentor
>>>>>>>> === package /big/home2/mika/2/cm3-cvs/fresh/cm3/m3-libs/
>>>>>>>> m3core ===
>>>>>>>> +++ /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/
>>>>>>>> home2/
>>>>>>>> mika/2/cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/
>>>>>>>> cm3 -
>>>>>>>> ship -DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' +++
>>>>>>>>
>>>>>>>>
>>>>>>>> ***
>>>>>>>> *** runtime error:
>>>>>>>> *** <*ASSERT*> failed.
>>>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690
>>>>>>>> ***
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ***
>>>>>>>> *** runtime error:
>>>>>>>> *** <*ASSERT*> failed.
>>>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690
>>>>>>>> ***
>>>>>>>
>>>>>>>> Abort trap
>>>>>>>> *** execution of failed ***
>>>>>>>>
>>>>>>>> This time it appears to be cm3 itself that's crashing:
>>>>>>>>
>>>>>>>> (310)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>$CM3 -keep -
>>>>>>>> commands
>>>>>>>>
>>>>>>>>
>>>>>>>> ***
>>>>>>>> *** runtime error:
>>>>>>>> *** <*ASSERT*> failed.
>>>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690
>>>>>>>> ***
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ***
>>>>>>>> *** runtime error:
>>>>>>>> *** <*ASSERT*> failed.
>>>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690
>>>>>>>> ***
>>>>>>>>
>>>>>>>> Abort
>>>>>>>>
>>>>>>>> What follows is what m3gdb has to say about this. I take it
>>>>>>>> that
>>>>>>>> the last error message comes from my -gstabs+ option. m3gdb
>>>>>>>> doesn't
>>>>>>>> like this new binary: it can't print variables and sometimes
>>>>>>>> crashes
>>>>>>>> trying. Would I have better luck with "-gstabs", do you
>>>>>>>> think? Or
>>>>>>>> do I just need to fix the compile process and install a new
>>>>>>>> m3gdb?
>>>>>>>> (I take it there is a newer one: mine is very old. But I
>>>>>>>> remember
>>>>>>>> that m3gdb doesn't always work that well...)
>>>>>>>>
>>>>>>>> Mika
>>>>>>>>
>>>>>>>> #1 16_81a619d in __raise ()
>>>>>>>> #2 16_81a3b8f in abort ()
>>>>>>>> #3 16_8178d16 in RTOS.Crash () at RTOS.m3:20
>>>>>>>> #4 16_8171fd2 in RTProcess.Crash (msg=NIL) at RTProcess.m3:65
>>>>>>>> #5 16_8170428 in RTError.EndError (crash=TRUE) at
>>>>>>>> RTError.m3:115
>>>>>>>> #6 16_8170169 in RTError.MsgS (file=16_820a508, line=690,
>>>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at
>>>>>>>> RTError.m3:40
>>>>>>>> #7 16_81707ec in RTException.Crash (a=RECORD exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL;
>>>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79
>>>>>>>> #8 16_8170550 in RTException.DefaultBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39
>>>>>>>> #9 16_81704b4 in RTException.InvokeBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25
>>>>>>>> #10 16_8179ca7 in RTException.Raise (act=RECORD exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL;
>>>>>>>> END) at RTExFrame.m3:29
>>>>>>>> #11 16_81705f0 in RTException.DefaultBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47
>>>>>>>> #12 16_81704b4 in RTException.InvokeBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25
>>>>>>>> #13 16_8179ca7 in RTException.Raise (act=RECORD exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL;
>>>>>>>> END) at RTExFrame.m3:29
>>>>>>>> #14 16_8160bba in RTHooks.ReportFault (module=16_820a680,
>>>>>>>> info=22080) at RTHooks.m3:110
>>>>>>>> #15 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0
>>>>>>>> #16 16_81649b7 in RTCollector.CollectorOn () at
>>>>>>>> RTCollector.m3:690
>>>>>>>> #17 16_816b595 in RTHooks.CheckLoadTracedRef
>>>>>>>> (ref=16_681b3300) at
>>>>>>>> RTCollector.m3:2296
>>>>>>>> #18 16_814400c in Stdio.ShutDown () at Stdio.m3:43
>>>>>>>> #19 16_8171f51 in RTProcess.InvokeExitors () at RTProcess.m3:40
>>>>>>>> #20 16_8171fc5 in RTProcess.Crash (msg=NIL) at RTProcess.m3:61
>>>>>>>> #21 16_8170428 in RTError.EndError (crash=TRUE) at
>>>>>>>> RTError.m3:115
>>>>>>>> #22 16_8170169 in RTError.MsgS (file=16_820a508, line=690,
>>>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at
>>>>>>>> RTError.m3:40
>>>>>>>> #23 16_81707ec in RTException.Crash (a=RECORD exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL;
>>>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79
>>>>>>>> #24 16_8170550 in RTException.DefaultBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39
>>>>>>>> #25 16_81704b4 in RTException.InvokeBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25
>>>>>>>> #26 16_8179ca7 in RTException.Raise (act=RECORD exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL;
>>>>>>>> END) at RTExFrame.m3:29
>>>>>>>> #27 16_81705f0 in RTException.DefaultBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47
>>>>>>>> #28 16_81704b4 in RTException.InvokeBackstop (a=RECORD
>>>>>>>> exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020;
>>>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25
>>>>>>>> #29 16_8179ca7 in RTException.Raise (act=RECORD exception =
>>>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc =
>>>>>>>> NIL;
>>>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL;
>>>>>>>> END) at RTExFrame.m3:29
>>>>>>>> #30 16_8160bba in RTHooks.ReportFault (module=16_820a680,
>>>>>>>> info=22080) at RTHooks.m3:110
>>>>>>>> #31 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0
>>>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at
>>>>>>>> RTCollector.m3:690
>>>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef
>>>>>>>> (ref=16_681b3004) at
>>>>>>>> RTCollector.m3:2296
>>>>>>>> #34 16_817c41e in ThreadF.ProcessStacks (p=16_816415e) at
>>>>>>>> ThreadPosix.m3:522
>>>>>>>> #35 16_8165213 in RTCollector.CollectSomeInStateZero () at
>>>>>>>> RTCollector.m3:845
>>>>>>>> #36 16_8164d2c in RTCollector.CollectSome () at
>>>>>>>> RTCollector.m3:741
>>>>>>>> #37 16_816487b in RTCollector.CollectEnough () at
>>>>>>>> RTCollector.m3:659
>>>>>>>> #38 16_81673cd in RTHeapRep.AllocTraced (def=16_81f8f38,
>>>>>>>> dataSize=8200, dataAlignment=4, initProc=16_bfbfe0f4,
>>>>>>>> pool=RECORD
>>>>>>>> desc = RECORD space = Current; generation = Younger; pure =
>>>>>>>> FALSE;
>>>>>>>> note = Allocated; gray = FALSE; clean = FALSE; continued =
>>>>>>>> FALSE; link = 0; END; notAfter = {Copied}; page = 0; stack = 0;
>>>>>>>> next = NIL; limit = NIL; busy = FALSE; END)
>>>>>>>> at RTCollector.m3:1417
>>>>>>>> #39 16_816218e in RTAllocator.GetOpenArray (def=16_81f8f38, s=
>>>>>>>> [2048]) at RTAllocator.m3:308
>>>>>>>> #40 16_8161737 in RTHooks.AllocateOpenArray (defn=16_81f8f38, s=
>>>>>>>> [2048]) at RTAllocator.m3:156
>>>>>>>> #41 16_8129d56 in M3ID_M3 (mode=1) at M3ID.m3:40
>>>>>>>> #42 16_816f802 in RTLinker.RunMainBody (m=16_81f8cc0) at
>>>>>>>> RTLinker.m3:399
>>>>>>>> #43 16_816f6ca in RTLinker.RunMainBody (m=16_81c0880) at
>>>>>>>> RTLinker.m3:379
>>>>>>>> #44 16_816f6ca in RTLinker.RunMainBody (m=16_81c06a0) at
>>>>>>>> RTLinker.m3:379
>>>>>>>> #45 16_816f6ca in RTLinker.RunMainBody (m=16_81bc920) at
>>>>>>>> RTLinker.m3:379
>>>>>>>> #46 16_816ed2d in RTLinker.AddUnitI (m=16_81bc920) at
>>>>>>>> RTLinker.m3:113
>>>>>>>> #47 16_816edb4 in RTLinker.AddUnit (b=16_8065527) at
>>>>>>>> RTLinker.m3:122
>>>>>>>> module "_m3main": missing debug info for global data
>>>>>>>>
>>>>>>>> (gdb) up 32
>>>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at
>>>>>>>> RTCollector.m3:690
>>>>>>>> RTCollector.m3:690: No such file or directory.
>>>>>>>> (gdb)
>>>>>>>> Suspended
>>>>>>>> (360)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>find ../.. -name
>>>>>>>> RTCollector.m3
>>>>>>>> ../../m3-libs/m3core/src/runtime/common/RTCollector.m3
>>>>>>>> (361)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>fg
>>>>>>>> m3gdb /usr/local/cm3/pkg/cm3/FreeBSD4/cm3
>>>>>>>> (gdb) dir ../../m3-libs/m3core/src/runtime/common/
>>>>>>>> Source directories searched: /big/home2/mika/2/cm3-cvs/fresh/
>>>>>>>> cm3/m3-
>>>>>>>> libs/m3core/../../m3-libs/m3core/src/runtime/common:$cdir:$cwd
>>>>>>>> (gdb) list
>>>>>>>> 685 VAR timeOnEntry, timeOnExit: Time.T; (* time of
>>>>>>>> collector entry/exit *)
>>>>>>>> 686
>>>>>>>> 687 PROCEDURE CollectorOn () =
>>>>>>>> 688 (* LL >= RTOS.LockHeap *)
>>>>>>>> 689 BEGIN
>>>>>>>> 690 <* ASSERT NOT collectorOn *>
>>>>>>>> 691 collectorOn := TRUE;
>>>>>>>> 692
>>>>>>>> 693 IF incremental AND NOT RTLinker.incremental
>>>>>>>> 694 OR generational AND NOT RTLinker.generational THEN
>>>>>>>> (gdb) print collectorOn
>>>>>>>> can't find identifier: collectorOn
>>>>>>>> (gdb) up
>>>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef
>>>>>>>> (ref=16_681b3004) at
>>>>>>>> RTCollector.m3:2296
>>>>>>>> 2296 CollectorOn();
>>>>>>>> (gdb) print collectorOn
>>>>>>>> can't find identifier: collectorOn
>>>>>>>> (gdb) print ref
>>>>>>>> Segmentation fault
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Assuming this succeeded then we can be pretty sure /usr/local/
>>>>>>>>> cm3/
>>>>>>>>> pkg/
>>>>>>>>> cm3/TARGET/cm3 is good, so we can make it our default
>>>>>>>>> compiler by
>>>>>>>>> replacing the original /usr/local/cm3/bin/cm3:
>>>>>>>>>
>>>>>>>>> cp $CM3 /usr/local/cm3/bin/cm3
>>>>>>>>>
>>>>>>>>> On Jun 23, 2007, at 2:38 PM, Mika Nystrom wrote:
>>>>>>>>>
>>>>>>>>>> Ok, I'm sorry if I seem a bit dimwitted in the morning like
>>>>>>>>>> this,
>>>>>>>>>> but how exactly does one get started? I wish there were a
>>>>>>>>>> file
>>>>>>>>>> called
>>>>>>>>>> "GETTING_STARTED" or something like that in scripts...
>>>>>>>>>>
>>>>>>>>>> My Mac is very slow so I switched to my FreeBSD/i386 system
>>>>>>>>>> (which has
>>>>>>>>>> PM3 happily installed on it) and tried to install CM3 from
>>>>>>>>>> scratch.
>>>>>>>>>> Here are the exact commands I typed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> rm -rf /usr/local/cm3/*
>>>>>>>>>>
>>>>>>>>>> cd ~/cm3-cvs
>>>>>>>>>> mkdir boot
>>>>>>>>>> cd boot
>>>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz
>>>>>>>>>> ./cminstall
>>>>>>>>>>
>>>>>>>>>> # now I seem to have some kind of cm3 installed, /usr/local/
>>>>>>>>>> cm3/
>>>>>>>>>> bin/
>>>>>>>>>> cm3
>>>>>>>>>>
>>>>>>>>>> cd cm3 # location of my CM3 checkout
>>>>>>>>>> cvs update -d .
>>>>>>>>>>
>>>>>>>>>> cd scripts
>>>>>>>>>> ./boot-cm3-with-m3.sh realclean
>>>>>>>>>> ./do-cm3-std.sh realclean
>>>>>>>>>>
>>>>>>>>>> ./upgrade.sh # fails here, libm3 not
>>>>>>>>>> compiled
>>>>>>>>>> ./boot-cm3-with-m3.sh build # builds cm3, but fails on
>>>>>>>>>> cminstall, patternmatching not built
>>>>>>>>>>
>>>>>>>>>> ./do-cm3-std.sh build # OK
>>>>>>>>>> ./do-cm3-std.sh buildship # OK
>>>>>>>>>>
>>>>>>>>>> ./boot-cm3-with-m3.sh realclean # start over
>>>>>>>>>> ./boot-cm3-with-m3.sh build # OK
>>>>>>>>>> ./boot-cm3-with-m3.sh buildship # OK
>>>>>>>>>>
>>>>>>>>>> ./do-cm3-std.sh realclean # OK
>>>>>>>>>> ./do-cm3-std.sh build # dies miserably... maybe
>>>>>>>>>> the
>>>>>>>>>> compiler can't handle the new libraries?
>>>>>>>>>>
>>>>>>>>>> ./install-cm3-compiler.sh upgrade # OK, new cm3 binary
>>>>>>>>>> installed
>>>>>>>>>>
>>>>>>>>>> After all that, "game over." I have a cm3 that segfaults.
>>>>>>>>>>
>>>>>>>>>> Text.i3: In function 'Text_I3':
>>>>>>>>>> Text.i3:81: internal compiler error: Segmentation fault
>>>>>>>>>> Please submit a full bug report,
>>>>>>>>>> with preprocessed source if appropriate.
>>>>>>>>>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>>>>>>>>> compilation failed => not building library "libm3core.a"
>>>>>>>>>> Fatal Error: package build failed
>>>>>>>>>> *** execution of failed ***
>>>>>>>>>>
>>>>>>>>>> I can't seem to get either m3gdb or gdb to say anything
>>>>>>>>>> reasonable
>>>>>>>>>> either. ktrace shows nothing out of the ordinary.
>>>>>>>>>>
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> Meanwhile, my Mac got through "do-cm3-std.sh realclean" and
>>>>>>>>>> "do-cm3-std.sh buildship" but my compiles are still dying
>>>>>>>>>> on the
>>>>>>>>>> same assertion tickled by ktok. On that machine I have
>>>>>>>>>> INSTALLROOT
>>>>>>>>>> set to ~/cm3, but hopefully that has nothing to do with it...
>>>>>>>>>>
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>> Does do-cm3-std.sh realclean clean EVERYTHING? If so my Mac
>>>>>>>>>> should
>>>>>>>>>> really have a fresh setup. The FreeBSD, I am not sure, maybe
>>>>>>>>>> the
>>>>>>>>>> old binary version just doesn't work right? Of course I
>>>>>>>>>> could try
>>>>>>>>>> bootstrapping with PM3 as well... but really, there's an
>>>>>>>>>> "approved"
>>>>>>>>>> process to get from a blank system, no?
>>>>>>>>>>
>>>>>>>>>> Mika
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tony Hosking writes:
>>>>>>>>>>> That sounds like you forgot to execute "do-cm3-std.sh
>>>>>>>>>>> realclean"
>>>>>>>>>>> before initiating the build. These sorts of errors sometimes
>>>>>>>>>>> arise
>>>>>>>>>>> if there are old build directories lying around.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jun 23, 2007, at 3:34 AM, Mika Nystrom wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> I am in the process of trying to consolidate build systems
>>>>>>>>>>>> for a
>>>>>>>>>>>> few software packages I am maintaining. Currently, I am
>>>>>>>>>>>> using an
>>>>>>>>>>>> old PM3 on FreeBSD4, an ancient PM3 (from Klagenfurt?) for
>>>>>>>>>>>> Windows
>>>>>>>>>>>> (NT386GNU), and trying to get the latest CM3 from cvs up and
>>>>>>>>>>>> compiling
>>>>>>>>>>>> things on PPC_DARWIN. Ideally, I'd like to standardize
>>>>>>>>>>>> everything
>>>>>>>>>>>> on the new PM3---mainly so that I can use pickles (and
>>>>>>>>>>>> Network
>>>>>>>>>>>> Objects) across all three systems. I'd also like to add
>>>>>>>>>>>> Linux to
>>>>>>>>>>>> the mix.
>>>>>>>>>>>>
>>>>>>>>>>>> It's natural for me to start with CM3 on Darwin, as
>>>>>>>>>>>> there's no
>>>>>>>>>>>> alternative. But I am getting some assertions failing.
>>>>>>>>>>>> Everything
>>>>>>>>>>>> in the CM3 distribution compiles fine, and I believe I have
>>>>>>>>>>>> compiled
>>>>>>>>>>>> the libraries a few times (that is, including with
>>>>>>>>>>>> themselves),
>>>>>>>>>>>> and
>>>>>>>>>>>> updated the compiler, too (using boot-cm3-with-m3.sh). I
>>>>>>>>>>>> just cvs
>>>>>>>>>>>> updated tonight.
>>>>>>>>>>>>
>>>>>>>>>>>> Here's what I'm running into:
>>>>>>>>>>>>
>>>>>>>>>>>> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/CHP.t -o
>>>>>>>>>>>> CHPTok.i3
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ***
>>>>>>>>>>>> *** runtime error:
>>>>>>>>>>>> *** <*ASSERT*> failed.
>>>>>>>>>>>> *** file "../src/runtime/common/RTCollector.m3", line
>>>>>>>>>>>> 2314
>>>>>>>>>>>> ***
>>>>>>>>>>>>
>>>>>>>>>>>> Abort
>>>>>>>>>>>>
>>>>>>>>>>>> Also:
>>>>>>>>>>>>
>>>>>>>>>>>> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o
>>>>>>>>>>>> PRSTok.i3
>>>>>>>>>>>> Illegal instruction
>>>>>>>>>>>>
>>>>>>>>>>>> As you can see, these things are coming from the
>>>>>>>>>>>> caltech_parser. I
>>>>>>>>>>> am using
>>>>>>>>>>>> our local version, but I don't think it is very different
>>>>>>>>>>>> from
>>>>>>>>>>>> what
>>>>>>>>>>>> is in the
>>>>>>>>>>>> CM3 tree.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Examining the first error (the failed assertion) more
>>>>>>>>>>>> closely,
>>>>>>>>>>>> I see
>>>>>>>>>>>> the following:
>>>>>>>>>>>>
>>>>>>>>>>>> (gdb) list
>>>>>>>>>>>> 108 wr := FileWr.Open(Pathname.ReplaceExt(tp.out,
>>>>>>>>>>>> "m3"));
>>>>>>>>>>>> 109 EXCEPT OSError.E =>
>>>>>>>>>>>> 110 Debug.Error("Cannot open tok implementation
>>>>>>>>>>>> output
>>>>>>>>>>>> file: " &
>>>>>>>>>>>> 111 Pathname.ReplaceExt(tp.out, "m3"));
>>>>>>>>>>>> 112 END;
>>>>>>>>>>>> 113 Wr.PutText(wr, subs.apply(Bundle.Get(Form,
>>>>>>>>>>>> "tokform.m3")));
>>>>>>>>>>>> 114 Wr.Close(wr);
>>>>>>>>>>>> 115 END Main.
>>>>>>>>>>>> (gdb) where
>>>>>>>>>>>> #0 0x9004308c in kill ()
>>>>>>>>>>>> #1 0x9009fb3c in abort ()
>>>>>>>>>>>> #2 0x00096f50 in RTOS__Crash () at RTOS.m3:20
>>>>>>>>>>>> #3 0x0005bd40 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at
>>>>>>>>>>>> RTProcess.m3:65
>>>>>>>>>>>> #4 0x0008e4e0 in RTError__EndError (M3_AicXUJ_crash=1
>>>>>>>>>>>> '\001') at
>>>>>>>>>>>> RTError.m3:115
>>>>>>>>>>>> #5 0x0008e08c in RTError__MsgS (M3_AJWxb1_file=0xc63d8,
>>>>>>>>>>>> M3_AcxOUs_line=2314, M3_Bd56fi_msgA=0xca3d0,
>>>>>>>>>>>> M3_Bd56fi_msgB=0xcbe90, M3_Bd56fi_msgC=0xca3d0) at
>>>>>>>>>>>> RTError.m3:40
>>>>>>>>>>>> #6 0x0008eb88 in RTException__Crash
>>>>>>>>>>>> (M3_Cblw37_a=0xbfffee00,
>>>>>>>>>>>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0xcb538) at
>>>>>>>>>>>> RTException.m3:79
>>>>>>>>>>>> #7 0x0008e74c in RTException__DefaultBackstop
>>>>>>>>>>>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at
>>>>>>>>>>>> RTException.m3:39
>>>>>>>>>>>> #8 0x0008e614 in RTException__InvokeBackstop
>>>>>>>>>>>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at
>>>>>>>>>>>> RTException.m3:25
>>>>>>>>>>>> #9 0x00095d04 in RTException__Raise
>>>>>>>>>>>> (M3_Cblw37_act=0xbfffee00) at
>>>>>>>>>>>> RTExFrame.m3:29
>>>>>>>>>>>> #10 0x0008e840 in RTException__DefaultBackstop
>>>>>>>>>>>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at
>>>>>>>>>>>> RTException.m3:47
>>>>>>>>>>>> #11 0x0008e614 in RTException__InvokeBackstop
>>>>>>>>>>>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at
>>>>>>>>>>>> RTException.m3:25
>>>>>>>>>>>> #12 0x00095d04 in RTException__Raise
>>>>>>>>>>>> (M3_Cblw37_act=0xbfffee00) at
>>>>>>>>>>>> RTExFrame.m3:29
>>>>>>>>>>>> #13 0x00079740 in RTHooks__ReportFault
>>>>>>>>>>>> (M3_AJWxb1_module=0xb3eb8,
>>>>>>>>>>>> M3_AcxOUs_info=74048) at RTHooks.m3:110
>>>>>>>>>>>> #14 0x0006ff4c in _m3_fault (M3_AcxOUs_arg=74048)
>>>>>>>>>>>> #15 0x0006bcf4 in RTHooks__CheckStoreTraced
>>>>>>>>>>>> (M3_Af40ku_ref=0xb2415c) at RTCollector.m3:2314
>>>>>>>>>>>> #16 0x000700e4 in ThreadPThread__InnerLockMutex
>>>>>>>>>>>> (M3_AYIbX3_m=0xb2415c, M3_BXP32l_self=0xb24014) at
>>>>>>>>>>>> ThreadPThread.m3:126
>>>>>>>>>>>> #17 0x000704d8 in ThreadPThread__LockMutex
>>>>>>>>>>>> (M3_AYIbX3_m=0xb2415c)
>>>>>>>>>>>> at ThreadPThread.m3:153
>>>>>>>>>>>> #18 0x00019b24 in Wr__PutText (M3_BxxOH1_wr=0xb2415c,
>>>>>>>>>>>> M3_Bd56fi_t=0xb44d5c) at Wr.m3:93
>>>>>>>>>>>> #19 0x00003f74 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113
>>>>>>>>>>>> #20 0x0005b1c4 in RTLinker__RunMainBody
>>>>>>>>>>>> (M3_DjPxE3_m=0xad190) at
>>>>>>>>>>>> RTLinker.m3:399
>>>>>>>>>>>> #21 0x00059f88 in RTLinker__AddUnitI
>>>>>>>>>>>> (M3_DjPxE3_m=0xad190) at
>>>>>>>>>>>> RTLinker.m3:113
>>>>>>>>>>>> #22 0x0005a084 in RTLinker__AddUnit (M3_DjPxE5_b=0x3600) at
>>>>>>>>>>>> RTLinker.m3:122
>>>>>>>>>>>> #23 0x00001fac in main (argc=4, argv=0xbffffb24,
>>>>>>>>>>>> envp=0xbffffb38)
>>>>>>>>>>>> at _m3main.mc:4
>>>>>>>>>>>> (gdb)
>>>>>>>>>>>>
>>>>>>>>>>>> The second error:
>>>>>>>>>>>>
>>>>>>>>>>>> Program received signal EXC_BAD_INSTRUCTION, Illegal
>>>>>>>>>>>> instruction/
>>>>>>>>>>>> operand.
>>>>>>>>>>>> 0x00b111ac in ?? ()
>>>>>>>>>>>> (gdb) where
>>>>>>>>>>>> #0 0x00b111ac in ?? ()
>>>>>>>>>>>> #1 0x0001214c in TextSubs__Apply (M3_CN69dV_self=0xb26450,
>>>>>>>>>>>> M3_Bd56fi_src=0xb21cec) at TextSubs.m3:63
>>>>>>>>>>>> #2 0x0005b1c4 in RTLinker__RunMainBody
>>>>>>>>>>>> (M3_DjPxE3_m=0xad190) at
>>>>>>>>>>>> RTLinker.m3:399
>>>>>>>>>>>> #3 0x00059f88 in RTLinker__AddUnitI
>>>>>>>>>>>> (M3_DjPxE3_m=0xad190) at
>>>>>>>>>>>> RTLinker.m3:113
>>>>>>>>>>>> #4 0x0005a084 in RTLinker__AddUnit (M3_DjPxE5_b=0x3600) at
>>>>>>>>>>>> RTLinker.m3:122
>>>>>>>>>>>> #5 0x00001fac in main (argc=4, argv=0xbffffb24,
>>>>>>>>>>>> envp=0xbffffb38)
>>>>>>>>>>>> at _m3main.mc:4
>>>>>>>>>>>> (gdb) list
>>>>>>>>>>>> 58 BEGIN
>>>>>>>>>>>> 59 WHILE pos < textLen DO
>>>>>>>>>>>> 60 c := Text.GetChar(src, pos);
>>>>>>>>>>>> 61 IF c IN self.starts THEN
>>>>>>>>>>>> 62 (* S("analysing: " & Text.Sub(src, pos),
>>>>>>>>>>>> DebugLevel); *)
>>>>>>>>>>>> 63 iter := self.tbl.iterateOrdered();
>>>>>>>>>>>> 64 ind := pos;
>>>>>>>>>>>> 65 original := "";
>>>>>>>>>>>> 66 REPEAT
>>>>>>>>>>>> 67 INC(ind);
>>>>>>>>>>>> (gdb)
>>>>>>>>>>>>
>>>>>>>>>>>> Any ideas what to look at?
>>>>>>>>>>>>
>>>>>>>>>>>> I don't know if this is relevant:
>>>>>>>>>>>>
>>>>>>>>>>>> [lapdog:~/t/cit_parse/PPC_DARWIN] mika% uname -a
>>>>>>>>>>>> Darwin lapdog.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
>>>>>>>>>>>> Mar 30
>>>>>>>>>>>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC
>>>>>>>>>>>> Power
>>>>>>>>>>>> Macintosh powerpc
>>>>>>>>>>>> [lapdog:~/t/cit_parse/PPC_DARWIN] mika% gcc -v
>>>>>>>>>>>> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
>>>>>>>>>>>> Thread model: posix
>>>>>>>>>>>> gcc version 3.3 20030304 (Apple Computer, Inc. build 1666)
>>>>>>>>>>>>
>>>>>>>>>>>> Mika
>>>>>>>>>>>>
>>>>>>>>>>>> P.S. Am I correct in assuming that I can get CM3 to build on
>>>>>>>>>>>> Windows?
>>>>>>>>>>>> I could switch to CM3 on Unix any time, of course, but I've
>>>>>>>>>>>> never
>>>>>>>>>>>> had luck with it on Windows, which is why I am using the
>>>>>>>>>>>> ancient
>>>>>>>>>>>> Klagenfurt PM3, which comes on 40-odd "floppies" and a .EXE
>>>>>>>>>>>> that
>>>>>>>>>>>> unpacks them into C: (and installation instructions only in
>>>>>>>>>>>> German).
>>>>>>>>>>>> If CM3 doesn't work on Windows, I am essentially wasting my
>>>>>>>>>>>> time,
>>>>>>>>>>>> as the current project I am working on absolutely requires
>>>>>>>>>>>> that
>>>>>>>>>>>> the
>>>>>>>>>>>> software run on Windows 2003 Server (yes, it sucks, but
>>>>>>>>>>>> what can
>>>>>>>>>>>> you do?) The very old PM3 at least kind of hobbles along on
>>>>>>>>>>>> this
>>>>>>>>>>>> platform---actually, better than that; it does Trestle
>>>>>>>>>>>> natively
>>>>>>>>>>>> under Windows (no X required), at least on SOME Windows
>>>>>>>>>>>> machines.
>>>>>>>>>>>>
>>>>>>>>>>>> P.P.S. Sorry for all the postscripts, but is it true that
>>>>>>>>>>>> the
>>>>>>>>>>>> build system has been changed so that building with
>>>>>>>>>>>> overrides
>>>>>>>>>>>> (cm3 -x)
>>>>>>>>>>>> requires having the compiler sources available? It didn't
>>>>>>>>>>>> use to
>>>>>>>>>>>> be that way, but I can't get Network Objects to work with
>>>>>>>>>>>> overrides
>>>>>>>>>>>> now unless I have the sources available... It's a bit of a
>>>>>>>>>>>> pain
>>>>>>>>>>>> because it means that every user has to have the compiler
>>>>>>>>>>>> sources,
>>>>>>>>>>>> or else ship everything, or was that not the intention?
More information about the M3devel
mailing list