[M3devel] pthreads issues [was: Re: strange errors... ]
Tony Hosking
hosking at cs.purdue.edu
Thu Jul 19 17:27:48 CEST 2007
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