[M3devel] pthreads issues [was: Re: strange errors... ]
Tony Hosking
hosking at cs.purdue.edu
Mon Jul 16 18:57:28 CEST 2007
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