[M3devel] pthreads issues [was: Re: strange errors... ]
Tony Hosking
hosking at cs.purdue.edu
Mon Jul 16 14:51:06 CEST 2007
On Jul 16, 2007, at 2:27 AM, Mika Nystrom wrote:
> An update:
>
> I was able to get everything to build by using @M3noincremental.
Yes, this makes sense, since the error is one that can only occur
with incremental GC.
>
> 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.
Odd. Please fill me in.
> 2. The assert when spawning threads in mentor, mentioned earlier.
I've not seen this since the fix I made a few weeks ago. It was
related to weak references.
> 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).
Cool. Another bug to chase.
> 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.
I'd appreciate any hints you can give. What platform? Possibly
related to thread stopping/restarting.
> 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
> ***
That doesn't mesh with the latest version of ThreadPThread.m3. Are
you sure you are up to date?
>
>
> 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