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