[M3devel] pthreads issues [was: Re: strange errors... ]
Tony Hosking
hosking at cs.purdue.edu
Fri Jul 20 17:42:27 CEST 2007
On Jul 20, 2007, at 3:16 AM, Mika Nystrom wrote:
> 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:
Possibly.
>
>
> ***
> *** 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).
Maybe you had stale code in the build directories? Glad to hear it
went away after recompiling.
> 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
> ***
>
That is an assert regarding setting the stack size. I wonder if this
is a Thread.SizedClosure which has a size value that asks for a stack
size less than PTHREAD_STACK_MIN. I am not sure what the best way to
handle that is except to disregard the return value from
pthread_attr_setstacksize. Can you try replacing line 675 in
ThreadPThread.m3 with:
EVAL Upthread.attr_setstacksize(attr, bytes);
and rebuilding? I am surprised to see that error though, since you
will note that I get the default stack size from a freshly
initialized attributes structure on line 673 and use the greater of
the default size and the requested size.
>
> 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.
Weird, I was running Bresenham just fine yesterday after the fix I
checked in. Sounds like you may have some stale object files lying
around.
> 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...
I was not aware that you are mixing cm3.cfg versions. Why do you
need both an old and a new one? In any case, this suggests that you
want to rebuild the new system using the proper cm3.cfg and see if
your problems go away.
> Mika
>
> P.S. I agree with you that 8000 threads is ample and good going for
> pthreads.
Great!
>
> 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