[M3devel] pthreads issues [was: Re: strange errors... ]
Mika Nystrom
mika at async.caltech.edu
Fri Jul 20 09:16:09 CEST 2007
Hi again Tony,
I am wondering, is it at all possible you might have to compile the new
compiler with itself to get it to generate the proper code? I was
at first able to get Juno to crash:
***
*** runtime error:
*** <*ASSERT*> failed.
*** file "../src/JunoRT.m3", line 698
***
but after recompiling a second time, it no longer seems to do that.
By the way, I am somewhat suspicious that this Juno crash has
something to do with threading: if you look closely, that part of
Juno has to do with thread switching into and out of the
Juno-machine...which is why I was happy to see it disappear (however
it did that).
I still have a threading crash in mentor. I run "Wheeler" to get this
one...
gdb /usr/local/cm3/bin/mentor
GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .......................................... done
(gdb) run
Starting program: /usr/local/cm3/bin/mentor
Reading symbols for shared libraries .++++++++++++++++++++.++++++++++++++++++ done
***
*** runtime error:
*** <*ASSERT*> failed.
*** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675
***
Program exited with code 01.
(gdb) where
No stack.
(gdb)
cvs status ./m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3
===================================================================
File: ThreadPThread.m3 Status: Up-to-date
Working revision: 1.34
Repository revision: 1.34 /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v
Commit Identifier: GYzMl9TO92Eakoqs
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
[QT:~/cm3] mika%
OS: 10.4 / ppc
(My 10.3 machine is in for service at the moment.)
Also the Bresenham demo just dies for me now, but that could of
course be a bug in mentor. It was working great the other day..
not sure what happened there.
I really don't think it's my old system that's corrupting the new images,
but I am *never* 100% certain of that. I found a very weird behavior
with the build system, actually. I found that the not-yet-installed
compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in
/usr/local/cm3/bin, but *only* if that is in the shell PATH. Is that
a known/desired behavior? It causes the brand new compiler to use the
old cm3.cfg, and it does so quietly without any warnings or messages
whatsoever. Changing your PATH makes it stop do that and instead crash,
prompting me to put the cm3.cfg I want in the right place...
Mika
P.S. I agree with you that 8000 threads is ample and good going for
pthreads.
Tony Hosking writes:
>Mika,
>
>I have diagnosed and fixed the problems you were seeing with thread
>pausing and alerts. mentor no longer exhibits the bug you reported
>and diagnosed. Thanks! I am starting to feel much more confident
>about the threads subsystem now that I am able to run mentor's
>functionality without problems on my Darwin 10.4.10 system using
>pthreads. There are still the capacity problems (number of pthreads
>beyond 8000) on Darwin, but that is a system issue not a problem with
>the pthreads implementation. For large numbers of threads the user-
>level implementation still seems the way to go. I want to update
>that to use getcontext/setcontext ASAP so that it will function again
>on platforms that have implemented secure (encrypting) versions of
>setjmp/longjmp that prevent stack hacks like those used to implement
>the current user-level threads system. Thanks again for your help,
>and please let me know of any further issues.
>
>-- Tony
>
>On Jul 17, 2007, at 3:31 AM, Mika Nystrom wrote:
>
>> Hi Tony,
>>
>> I have a friend with a 10.4.10 system,
>>
>> Darwin QT.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23
>> 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh
>> powerpc
>>
>> I used your instructions again, installing from the CVS head. You're
>> right, things are different on this OS! The programs that were
>> taking 100% cpu (mine as well as the ones in the distribution) on
>> my 10.3 system are not doing that on the the 10.4 system. ktok
>> still crashes, now sometimes with an illegal instruction, sometimes
>> at line 2310, as before.
>>
>> After some fiddling, during which mentor worked far better than on
>> 10.3, I was able to get mentor to---as it appears---deadlock. The
>> Bresenham demo seems to deadlock mentor pretty reliably for me.
>> Here's a traceback from hitting ctrl-C after mentor has gone
>> catatonic:
>>
>> (gdb) where
>> #0 0x9002c3c8 in semaphore_wait_signal_trap ()
>> #1 0x90030eac in pthread_cond_wait ()
>> #2 0x01d2d83c in ThreadPThread__InnerWait (M3_AYIbX3_m=0x2860540,
>> M3_Bl0jv4_c=0x2a43b24, M3_BXP32l_self=0x2860014) at
>> ThreadPThread.m3:212
>> #3 0x01d2dc6c in Thread__Wait (M3_AYIbX3_m=0x2860540,
>> M3_Bl0jv4_c=0x2a43b24) at ThreadPThread.m3:251
>> #4 0x018991d8 in Trestle__AwaitDelete (M3_BFdKo9_v=0x2a0a9cc) at
>> Trestle.m3:884
>> #5 0x0120b058 in ZeusPanel__Interact (M3_Bd56fi_title=0x36ace0,
>> M3_DYb95R_path=0x2863f94) at ZeusPanel.m3:477
>> #6 0x0028af0c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:165
>> #7 0x01d16654 in RTLinker__RunMainBody (M3_DjPxE3_m=0x2b1428) at
>> RTLinker.m3:399
>> #8 0x01d15418 in RTLinker__AddUnitI (M3_DjPxE3_m=0x2b1428) at
>> RTLinker.m3:113
>> #9 0x01d15514 in RTLinker__AddUnit (M3_DjPxE5_b=0x28ae88) at
>> RTLinker.m3:122
>> #10 0x00002a44 in main (argc=1, argv=0xbffffc98, envp=0xbffffca0)
>> at _m3main.mc:4
>>
>> My program that was having trouble with pickles now does the
>> following. It is reading data out of a disk file that it has
>> recently written using Pickle.Write. I'm afraid I can't give out
>> the source code for this program, so I'll have to isolate a simpler
>> case. Btw, this happens also with @M3nogc. No UNSAFE code of any
>> kind involved here. Attempting to access the arguments of Text.Equal
>> through gdb crashes gdb with a bus error. If someone has an idea
>> (even a vague one) what might be the problem I could spend some
>> time poking around the code...
>>
>> ((1)) FIXPersistentState.Init: initialized tbl backed by "states/
>> asdfw_25fwds.snt"
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>> 0x900031c8 in strlen ()
>> (gdb) where
>> #0 0x900031c8 in strlen ()
>> #1 0x01671c70 in Text8CString__GetInfo (M3_A8R5P5_t=0x1fb17f8,
>> M3_BUgnwf_info=0xbfffe4bc) at Text8CString.m3:23
>> #2 0x0166dbd4 in Text__Equal (M3_Bd56fi_t=0x1fb17f8,
>> M3_Bd56fi_u=0x1f9322c) at Text.m3:31
>> #3 0x003a8fd0 in FIXEngine__SanityCheckFields
>> (M3_EdNxIG_t=0x1f953b0, M3_Ck0t2u_msg=0x1fb177c) at FIXEngine.m3:259
>> #4 0x003aad58 in FIXEngine__InitSession (M3_EdNxIG_t=0x1f953b0,
>> M3_CVvbAZ_session=0x1f93290) at FIXEngine.m3:450
>> #5 0x003a9ad4 in FIXEngine__Init (M3_EdNxIG_t=0x1f953b0,
>> M3_Cbj6ab_conn=0x1f95454, M3_CqtnCQ_mode=0 '\0',
>> M3_Cwb5VA_heartBtInt=<unknown type>, M3_CVvbAZ_session=0x1f93290,
>> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001',
>> M3_Cwb5VA_logonAttempts=<unknown type>, M3_Cwb5VA_minSid=<unknown
>> type>) at FIXEngine.m3:321
>> #6 0x0022de58 in FIXTradingMonitor__StartEngine
>> (M3_D2FCrJ_t=0x1f95178) at FIXTradingMonitor.m3:179
>> #7 0x0022dba8 in FIXTradingMonitor__Init (M3_D2FCrJ_t=0x1f95178,
>> M3_Ba2nJq_tcpMaker=0x1f95014, M3_CVvbAZ_session=0x1f93290,
>> M3_DdEwXy_state=0x1f95000, M3_Cwb5VA_heartBtInt=<unknown type>,
>> M3_Cwb5VA_minSid=<unknown type>) at FIXTradingMonitor.m3:166
>> #8 0x00005308 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:218
>> #9 0x0163d654 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6018) at
>> RTLinker.m3:399
>> #10 0x0163c418 in RTLinker__AddUnitI (M3_DjPxE3_m=0x6018) at
>> RTLinker.m3:113
>> #11 0x0163c514 in RTLinker__AddUnit (M3_DjPxE5_b=0x3648) at
>> RTLinker.m3:122
>> #12 0x0000320c in main (argc=10, argv=0xbffff61c, envp=0xbffff648)
>> at _m3main.mc:4
>> (gdb)
>>
>> Juno crashes in JunoRT.m3 if you try to do anything fancy, but I
>> suppose that is more likely a bug (bit rot?) in Juno than in the
>> system...
>>
>> Also all the linker flags seem to be different (linking with C code
>> against your cm3.cfg doesn't work so well for some reason), but
>> that's all minor stuff, I think.
>>
>> Mika
>>
>>
>> Tony Hosking writes:
>>> 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