From mika at async.caltech.edu Mon Jul 2 12:35:48 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 02 Jul 2007 03:35:48 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Thu, 28 Jun 2007 10:53:25 EDT." Message-ID: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:03:42 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:03:42 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:05:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:05:36 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: <3B964979-AD2A-41FD-8522-3B1D00D9CE9A@cs.purdue.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:49:57 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:49:57 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: <39E88F42-57CE-4AE0-8ED8-AF955B6A0E26@cs.purdue.edu> In follow up to my previous message, I think I may have a simpler fix. Can you please try the latest version of ThreadPosix.m3 that I just checked in. Unfortunately, I don't have a user-level threads system on which to try (Linux is broken because setjmp/longjmp use encryption to prevent stack-smashing security exploits), and my Solaris boxes are not available right now. 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 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? From dabenavidesd at yahoo.es Mon Jul 2 18:05:22 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 2 Jul 2007 18:05:22 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: Message-ID: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> Hi: In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the same problem is happensg, with the message of the RTCollector danielb at danielb-desktop:~$ mentor *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/runtime/common/RTCollector.m3", line 2310 *** Aborted danielb at danielb-desktop:~$ With the @M3noincremental runs fine, @M3nogc also doesnt break. --- Tony Hosking wrote: > 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, === message truncated === ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From hosking at cs.purdue.edu Mon Jul 2 21:50:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 15:50:44 -0400 Subject: [M3devel] strange errors... In-Reply-To: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> References: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> Message-ID: This problem has been fixed by the most recent update to RTCollector.m3, with respect to handling of weak references. On Jul 2, 2007, at 12:05 PM, Daniel Alejandro Benavides D. wrote: > Hi: > In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the > same problem is happensg, with the message of the > RTCollector > > danielb at danielb-desktop:~$ mentor > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", > line 2310 > *** > > Aborted > > danielb at danielb-desktop:~$ > > With the @M3noincremental runs fine, @M3nogc also > doesnt break. > > > > --- Tony Hosking wrote: > >> 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, > === message truncated === > > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. > http://es.voice.yahoo.com From hosking at cs.purdue.edu Mon Jul 2 22:01:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 16:01:26 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: Is there any chance this error is related to the fix I just made with respect to weak references? I am going to get a user-level setup working for my LINUXLIBC6 builds, so as to try and track this problem down. 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 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? From mika at async.caltech.edu Tue Jul 3 11:13:23 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 03 Jul 2007 02:13:23 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Mon, 02 Jul 2007 11:49:57 EDT." <39E88F42-57CE-4AE0-8ED8-AF955B6A0E26@cs.purdue.edu> Message-ID: <200707030913.l639DNDc012408@camembert.async.caltech.edu> Wow! It works! I am able to compile the various stages of bootstrap as well as run Juno, mentor, etc., without any @M3 hacks, on FreeBSD with the user-level threads, as of this afternoon's checkout (around 3 p.m. Pacific). On my quest to move on from various dusty PM3 decks, I am still struggling with some of my own code, which seems to be having issues with pickles, network objects, trestle, m3gdb, and a few other odds and ends, but I will return to those at a later date. All the garbage collector issues that I am aware of seem resolved on FreeBSD. A big thanks!!! Mika P.S. Tony, if you'd like a testing account on my home machine, which is running FreeBSD5.5-RELEASE/i386, just let me know. Of course I'm happy to try updating and compiling things, too. Tony Hosking writes: >In follow up to my previous message, I think I may have a simpler >fix. Can you please try the latest version of ThreadPosix.m3 that I >just checked in. Unfortunately, I don't have a user-level threads >system on which to try (Linux is broken because setjmp/longjmp use >encryption to prevent stack-smashing security exploits), and my >Solaris boxes are not available right now. > >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 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? From hosking at cs.purdue.edu Tue Jul 3 17:28:59 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Jul 2007 11:28:59 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707030913.l639DNDc012408@camembert.async.caltech.edu> References: <200707030913.l639DNDc012408@camembert.async.caltech.edu> Message-ID: <58811923-05C1-45CF-A774-DE15BABD93B5@cs.purdue.edu> Excellent! The problem was in the way the weak references implementation squirrels away traced references and hides them from the run-time system. In my digging I have also discovered that there appears to be some sort of race in the VBT code that leads to double-release of a lock. It appears not to be GC-related. Is anyone familiar enough with the VBT code to diagnose this? It always happens at the same place: #0 ThreadPThread__Die (M3_AcxOUs_lineno=167, M3_Bd56fi_msg=0x1061088) at ThreadPThread.m3:1238 #1 0x010360d7 in ThreadPThread__InnerUnlockMutex (M3_AYIbX3_m=0xb4d127c4, M3_BXP32l_self=0xb4d1e010) at ThreadPThread.m3:167 #2 0x010362ee in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0xb4d127c4) at ThreadPThread.m3:188 #3 0x004dca26 in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d127c4, M3_BFdKo9_ch=0xb4d15164, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:799 #4 0x004d51dd in VBT__Sync (M3_BJ2YpW_v=0xb4d15164, M3_AicXUJ_wait=1 '\001') at VBT.m3:1167 #5 0x00524838 in JoinedVBT__Sync (M3_B2daE0_v=0xb4d12654, M3_BFdKo9_ch=0xb4d12730, M3_AicXUJ_wait=1 '\001') at JoinedVBT.m3:101 #6 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d12730, M3_BFdKo9_ch=0xb4d126b4, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #7 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d126b4, M3_BFdKo9_ch=0xb24c5e48, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #8 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb24c5e48, M3_BFdKo9_ch=0xb4d1e0b0, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #9 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d1e0b0, M3_BFdKo9_ch=0xb4d1e31c, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #10 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d1e31c, M3_BFdKo9_ch=0xb4d1e1a0, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #11 0x004d51dd in VBT__Sync (M3_BJ2YpW_v=0xb4d1e1a0, M3_AicXUJ_wait=1 '\001') at VBT.m3:1167 #12 0x00bcc273 in MGV__MGRedisplay (M3_AdEaVQ_v=0xb4d1e1a0, M3_A0Kbc5_br=0xcf2600) at MGV.m3:146 #13 0x00bb7fa1 in Animate__DoAnimation (M3_CCfZY3_t=0xb2506534, M3_BUucNs_time=0.157132864, M3_BUucNs_timePrev=0.156615973, M3_AdEaVQ_v=0xb4d1e1a0, M3_DsL7Zz_mg=0x0) at Animate.m3:57 #14 0x00bb80eb in Animate__Do (M3_CCfZY3_t=0xb2506534, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0xb4d1e1a0, M3_BUucNs_duration=1) at Animate.m3:74 #15 0x00bcd5c6 in MGV__Animation (M3_AdEaVQ_v=0xb4d1e1a0, M3_BUucNs_duration=1) at MGV.m3:313 #16 0x0031a3f3 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0xb4d1e0b0, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at GraphVBT.m3:656 #17 0x08077aec in PackingView3__Probe (M3_ClPWAg_view=0xb24c5e48, M3_AcxOUs_bin=1, M3_BUucNs_total=0.972417712) at PackingView3.m3:68 #18 0x0806c76c in BinpackIE__OEDispatcher (M3_Ao6Rbg_v=0xb24c5e48, M3_Af40ku_evt=0xb7fda068) at BinpackIE.m3:96 #19 0x001f83fb in Zeus__ViewThread (M3_BH3Tll_self=0xb4d22030) at Zeus.m3:331 #20 0x01038d80 in ThreadPThread__RunThread (M3_EkbOya_me=0x84c5b98) at ThreadPThread.m3:547 #21 0x01038895 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x84c5b98) at ThreadPThread.m3:517 #22 0x42a2a3db in start_thread () from /lib/libpthread.so.0 #23 0x4296f26e in clone () from /lib/libc.so.6 On Jul 3, 2007, at 5:13 AM, Mika Nystrom wrote: > > Wow! It works! I am able to compile the various stages of bootstrap > as well as run Juno, mentor, etc., without any @M3 hacks, on FreeBSD > with the user-level threads, as of this afternoon's checkout (around > 3 p.m. Pacific). On my quest to move on from various dusty PM3 > decks, I am still struggling with some of my own code, which seems > to be having issues with pickles, network objects, trestle, m3gdb, > and a few other odds and ends, but I will return to those at a later > date. All the garbage collector issues that I am aware of seem > resolved on FreeBSD. A big thanks!!! > > Mika > > P.S. Tony, if you'd like a testing account on my home machine, which > is running FreeBSD5.5-RELEASE/i386, just let me know. Of course > I'm happy to try updating and compiling things, too. > > Tony Hosking writes: >> In follow up to my previous message, I think I may have a simpler >> fix. Can you please try the latest version of ThreadPosix.m3 that I >> just checked in. Unfortunately, I don't have a user-level threads >> system on which to try (Linux is broken because setjmp/longjmp use >> encryption to prevent stack-smashing security exploits), and my >> Solaris boxes are not available right now. >> >> 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 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? From hosking at cs.purdue.edu Tue Jul 3 18:42:16 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Jul 2007 12:42:16 -0400 Subject: [M3devel] User-level threading Message-ID: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> I have a question that may influence the direction we take with user- level threading support. Currently, user-level threading is broken on platforms that implement secure setjmp/longjmp via encryption since hacking the jump buffers the way we currently do for user-level threading triggers longjmp errors. A better alternative is to use makecontext/getcontext/setcontext on platforms that support it. For example, I know of the following situation for the targets I track: Target System (pthreads) threads User (setjmp/longjmp) threads User (getcontext/setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES unimplemented YES (but not using makecontext) PPC_DARWIN YES NO no getcontext/setcontext I386_DARWIN YES NO no getcontext/setcontext FreeBSD NO YES unimplemented Ideally, we would implement all user-level threading using makecontext and friends, but my question is how many of our user- level threading targets actually support that API? One strategy would be to re-implement user-level threading using makecontext, etc., but fake up makecontext support, etc., on those targets that don't have it. I would hate to lose the user-level thread support just because it makes sense in some situations (e.g., embedded, uni-processor). From dragisha at m3w.org Tue Jul 3 23:37:54 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 03 Jul 2007 23:37:54 +0200 Subject: [M3devel] myId and inCritical.... Message-ID: <1183498674.9419.3.camel@faramir.m3w.org> Hallelujah! -- Dragi?a Duri? From mika at async.caltech.edu Wed Jul 4 14:10:39 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 04 Jul 2007 05:10:39 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Sun, 24 Jun 2007 10:38:34 EDT." Message-ID: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Hi again! I was able to boot the CVS head of CM3 on my Mac just fine now, using the cm3.cfg you sent me. I am still running the old OS (Panther, is it?) so I tried doing it the hard way instead of using your binaries, and I got something that works pretty well. Mentor and Juno work, at least, and that's usually a good indicator that one is on the right track... But (of course there's a "but"), I am still falling down on my very first reported bug, namely this local ktok program. I still, after all that you've done, find that it dies on an illegal instruction on the Macintosh (I am running 10.3 on a Powerbook). The problem goes away if I use either @M3nogc or @M3noincremental. The gdb backtrace is not very helpful: it says the program is crashing somewhere in a text processing module, creating an iterator on a sorted table. Sorry to do this but I am feeling a bit clueless, so if you're interested and have the time to look into it, I have set up a minimal test here: http://www.async.caltech.edu/~mika/ktok_example.tgz Unfortunately, ktok itself depends on a bunch of packages. To build this, set your CM3 environment variable to anything (1 works) and just "make" (GNU make, please). Set the DEBUGLEVEL environment variable to "10" for a bit more output (not much). The very last step (compiling package cit_parse) fails for me... Specifically, the step is: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 WELCOME! GOT TOKPARAMS! GOT TOKENS GOT SUBS! "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 4: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 Looking a bit closer: [lapdog:~/t/cit_parse/src] mika% gdb /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 Starting program: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 Reading symbols for shared libraries . done WELCOME! GOT TOKPARAMS! GOT TOKENS GOT SUBS! Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x00b111c8 in ?? () (gdb) where #0 0x00b111c8 in ?? () #1 0x000120e4 in TextSubs__Apply (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at TextSubs.m3:64 #2 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 #3 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 #4 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 #5 0x00001ecc in main (argc=4, argv=0xbffffadc, envp=0xbffffaf0) at _m3main.mc:4 (gdb) Also: PROCEDURE Apply(self: T; src: TEXT): TEXT = VAR wr := TextWr.New(); c: CHAR; ind, pos, lastFlushed: INTEGER := 0; textLen := Text.Length(src); iter: SortedTextTextTbl.Iterator; original, replacement: TEXT; key, prefix: TEXT; PROCEDURE Flush() = BEGIN Wr.PutText(wr, Text.Sub(src, lastFlushed, pos - lastFlushed)); END Flush; BEGIN WHILE pos < textLen DO c := Text.GetChar(src, pos); IF c IN self.starts THEN Debug.Out("analysing: " & Text.Sub(src, pos), 100); iter := self.tbl.iterateOrdered(); (* line 64 *) ind := pos; original := ""; REPEAT INC(ind); ... I am mystified as to why gdb would say that RTLinker__RunMainBody would be calling TextSubs__Apply. With @M3nogc or @M3noincremental, all is well... I will see if I can figure out more, but this problem just doesn't seem to want to go away. To the best of my knowledge, ktok doesn't use any UNSAFE code (outside of whatever's in libm3 of course). Mika 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: > >cd ~/cm3/scripts >./do-cm3-std.sh realclean >./do-cm3-std.sh buildship > >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 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? From wagner at elegosoft.com Wed Jul 4 17:32:12 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 4 Jul 2007 17:32:12 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> References: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Message-ID: <37423.194.138.127.36.1183563132.squirrel@mail.elegosoft.com> On Wed, July 4, 2007 2:10 pm, Mika Nystrom wrote: > Hi again! > > I was able to boot the CVS head of CM3 on my Mac just fine now, > using the cm3.cfg you sent me. I am still running the old OS > (Panther, is it?) so I tried doing it the hard way instead of using > your binaries, and I got something that works pretty well. Mentor > and Juno work, at least, and that's usually a good indicator that > one is on the right track... > > But (of course there's a "but"), I am still falling down on my very > first reported bug, namely this local ktok program. I still, after > all that you've done, find that it dies on an illegal instruction > on the Macintosh (I am running 10.3 on a Powerbook). > > The problem goes away if I use either @M3nogc or @M3noincremental. > The gdb backtrace is not very helpful: it says the program is > crashing somewhere in a text processing module, creating an iterator > on a sorted table. > > Sorry to do this but I am feeling a bit clueless, so if you're > interested and have the time to look into it, I have set up a minimal > test here: > > http://www.async.caltech.edu/~mika/ktok_example.tgz > > Unfortunately, ktok itself depends on a bunch of packages. > > To build this, set your CM3 environment variable to anything (1 > works) and just "make" (GNU make, please). Set the DEBUGLEVEL > environment variable to "10" for a bit more output (not much). The > very last step (compiling package cit_parse) fails for me... > Specifically, the step is: > > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime > error: exit 4: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o > PRSTok.i3 > > Looking a bit closer: > > [lapdog:~/t/cit_parse/src] mika% gdb > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) > Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 > Starting program: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o > PRSTok.i3 > Reading symbols for shared libraries . done > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > > Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. > 0x00b111c8 in ?? () > (gdb) where > #0 0x00b111c8 in ?? () > #1 0x000120e4 in TextSubs__Apply (M3_CN69dV_self=0xb26434, > M3_Bd56fi_src=0xb40be0) at TextSubs.m3:64 > #2 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at > RTLinker.m3:399 > #3 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 > #4 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 > #5 0x00001ecc in main (argc=4, argv=0xbffffadc, envp=0xbffffaf0) at > _m3main.mc:4 > (gdb) > > Also: > > PROCEDURE Apply(self: T; src: TEXT): TEXT = > VAR > wr := TextWr.New(); > c: CHAR; > ind, pos, lastFlushed: INTEGER := 0; > textLen := Text.Length(src); > iter: SortedTextTextTbl.Iterator; > original, replacement: TEXT; > key, prefix: TEXT; > PROCEDURE Flush() = > BEGIN > Wr.PutText(wr, Text.Sub(src, lastFlushed, pos - lastFlushed)); > END Flush; > BEGIN > WHILE pos < textLen DO > c := Text.GetChar(src, pos); > IF c IN self.starts THEN > Debug.Out("analysing: " & Text.Sub(src, pos), 100); > iter := self.tbl.iterateOrdered(); (* line 64 *) > ind := pos; > original := ""; > REPEAT > INC(ind); > ... > > I am mystified as to why gdb would say that RTLinker__RunMainBody > would be calling TextSubs__Apply. > > With @M3nogc or @M3noincremental, all is well... > > I will see if I can figure out more, but this problem just doesn't > seem to want to go away. To the best of my knowledge, ktok doesn't > use any UNSAFE code (outside of whatever's in libm3 of course). I cannot really tell you why there's a bad instruction in some of the module initialization code, but the RT linker is executing all the module bodies in correct order at the start of the program (at least it tries to :). So probably TextSubs.Apply is called from some module initialization code. Have you tried to run the program with @M3tracelinker to get some context to that call? It should print ouy all module names... This _may_ be helpful. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From elmstb at aon.at Wed Jul 4 20:12:04 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 20:12:04 +0200 Subject: [M3devel] User-level threading In-Reply-To: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> Message-ID: <468BE2F4.7010805@aon.at> Not long ago I have fixed this problem by replacing setjmp/longjmp with my own i386 - implementations of these functions for SRC-M3. The result seems to be stable and correct. However this may be less favourable than using makecontext since the assembler routines will only work on i386 hardware. Moreover setjmp/longjmp are said that they may cause the loss of assignents, because they do not save certain registers(cx,dx) -> see "Exception semantics" at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. Nevertheless possible future changes on make/get/setcontext will not be able to affect Modula-3 when extracting the SP from the context record any more if it does not rely on glibc functions. Another solution is to link against the old glibc files (unpacked into /lib/anc): > ldd $(which m3build) linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) Please tell me if you are intereseted in any of both solutions. I would suppose a solution for CM3 not to differ that much. Yours, Elmar Stellnberger Tony Hosking wrote: > I have a question that may influence the direction we take with > user-level threading support. Currently, user-level threading is > broken on platforms that implement secure setjmp/longjmp via > encryption since hacking the jump buffers the way we currently do for > user-level threading triggers longjmp errors. A better alternative is > to use makecontext/getcontext/setcontext on platforms that support it. > For example, I know of the following situation for the targets I track: > > Target System (pthreads) threads User (setjmp/longjmp) threads User > (getcontext/setcontext) threads > > LINUXLIBC6 YES NO unimplemented > SOLgnu YES unimplemented YES (but not using makecontext) > PPC_DARWIN YES NO no getcontext/setcontext > I386_DARWIN YES NO no getcontext/setcontext > FreeBSD NO YES unimplemented > > Ideally, we would implement all user-level threading using makecontext > and friends, but my question is how many of our user-level threading > targets actually support that API? One strategy would be to > re-implement user-level threading using makecontext, etc., but fake up > makecontext support, etc., on those targets that don't have it. > > I would hate to lose the user-level thread support just because it > makes sense in some situations (e.g., embedded, uni-processor). > > > From elmstb at aon.at Wed Jul 4 20:31:50 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 20:31:50 +0200 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468BE796.8020802@aon.at> It seems to be the same message, which I have sent to you. Has there been anything new you wanted to tell me? Is the setjmp/longjmp replacement of interest? Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > However this may be less favourable than using makecontext since the > assembler routines will only work on i386 hardware. > Moreover setjmp/longjmp are said that they may cause the loss of > assignents, because they do not save certain registers(cx,dx) -> see > "Exception semantics" at > http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. > Nevertheless possible future changes on make/get/setcontext will not be > able to affect Modula-3 when extracting the SP from the context record > any more if it does not rely on glibc functions. > Another solution is to link against the old glibc files (unpacked into > /lib/anc): > > >> ldd $(which m3build) >> > linux-gate.so.1 => (0xffffe000) > libm3front.so.1 => > /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) > libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) > libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) > /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) > > Please tell me if you are intereseted in any of both solutions. > I would suppose a solution for CM3 not to differ that much. > > Yours, > Elmar Stellnberger > > > > Tony Hosking wrote: > >> I have a question that may influence the direction we take with >> user-level threading support. Currently, user-level threading is >> broken on platforms that implement secure setjmp/longjmp via >> encryption since hacking the jump buffers the way we currently do for >> user-level threading triggers longjmp errors. A better alternative is >> to use makecontext/getcontext/setcontext on platforms that support it. >> For example, I know of the following situation for the targets I track: >> >> Target System (pthreads) threads User (setjmp/longjmp) threads User >> (getcontext/setcontext) threads >> >> LINUXLIBC6 YES NO unimplemented >> SOLgnu YES unimplemented YES (but not using makecontext) >> PPC_DARWIN YES NO no getcontext/setcontext >> I386_DARWIN YES NO no getcontext/setcontext >> FreeBSD NO YES unimplemented >> >> Ideally, we would implement all user-level threading using makecontext >> and friends, but my question is how many of our user-level threading >> targets actually support that API? One strategy would be to >> re-implement user-level threading using makecontext, etc., but fake up >> makecontext support, etc., on those targets that don't have it. >> >> I would hate to lose the user-level thread support just because it >> makes sense in some situations (e.g., embedded, uni-processor). >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jul 4 22:12:47 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Jul 2007 16:12:47 -0400 Subject: [M3devel] User-level threading In-Reply-To: <468BE796.8020802@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> <468BE796.8020802@aon.at> Message-ID: In looking at things again, I am more and more convinced that ThreadPosix should be implemented against the standard API for makecontext/getcontext/setcontext/swapcontext. Platforms that do not provide these will need to provide an equivalent implementation of these routines, similar to what you suggest. Right now, I know all of SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary support. On Jul 4, 2007, at 2:31 PM, Elmar Stellnberger wrote: > It seems to be the same message, which I have sent to you. > Has there been anything new you wanted to tell me? > Is the setjmp/longjmp replacement of interest? > > Elmar Stellnberger wrote: >> Not long ago I have fixed this problem by replacing setjmp/longjmp >> with my own i386 - implementations of these functions for SRC-M3. >> The result seems to be stable and correct. However this may be >> less favourable than using makecontext since the assembler >> routines will only work on i386 hardware. Moreover setjmp/longjmp >> are said that they may cause the loss of assignents, because they >> do not save certain registers(cx,dx) -> see "Exception semantics" >> at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/ >> restrictions.html. Nevertheless possible future changes on make/ >> get/setcontext will not be able to affect Modula-3 when extracting >> the SP from the context record any more if it does not rely on >> glibc functions. Another solution is to link against the old glibc >> files (unpacked into /lib/anc): >>> ldd $(which m3build) >> linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/ >> lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so. >> 6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/ >> libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) >> Please tell me if you are intereseted in any of both solutions. I >> would suppose a solution for CM3 not to differ that much. Yours, >> Elmar Stellnberger Tony Hosking wrote: >>> I have a question that may influence the direction we take with >>> user-level threading support. Currently, user-level threading is >>> broken on platforms that implement secure setjmp/longjmp via >>> encryption since hacking the jump buffers the way we currently do >>> for user-level threading triggers longjmp errors. A better >>> alternative is to use makecontext/getcontext/setcontext on >>> platforms that support it. For example, I know of the following >>> situation for the targets I track: Target System (pthreads) >>> threads User (setjmp/longjmp) threads User (getcontext/ >>> setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES >>> unimplemented YES (but not using makecontext) PPC_DARWIN YES NO >>> no getcontext/setcontext I386_DARWIN YES NO no getcontext/ >>> setcontext FreeBSD NO YES unimplemented Ideally, we would >>> implement all user-level threading using makecontext and friends, >>> but my question is how many of our user-level threading targets >>> actually support that API? One strategy would be to re-implement >>> user-level threading using makecontext, etc., but fake up >>> makecontext support, etc., on those targets that don't have it. I >>> would hate to lose the user-level thread support just because it >>> makes sense in some situations (e.g., embedded, uni-processor). > From wagner at elegosoft.com Wed Jul 4 22:25:16 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 4 Jul 2007 22:25:16 +0200 Subject: [M3devel] User-level threading In-Reply-To: References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> <468BE796.8020802@aon.at> Message-ID: <20070704202516.GA26977@elegosoft.com> On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: > In looking at things again, I am more and more convinced that > ThreadPosix should be implemented against the standard API for > makecontext/getcontext/setcontext/swapcontext. Platforms that do not > provide these will need to provide an equivalent implementation of > these routines, similar to what you suggest. Right now, I know all of > SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary > support. I think a `standard' implementation using makecontext/getcontext/... would be the best. For those platforms that do not support that, we can still use a C or assembler implementation. I would strongly vote for keeping user-level threading, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Wed Jul 4 23:35:13 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 Jul 2007 23:35:13 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Message-ID: <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Hi: I take the sources from the your web page and type make on the top of the directory v and end in this message: ===> cit_parse --- building in LINUXLIBC6 --- ignoring override("cit_parse", "/home/danielb/Desktop/v") /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x4000b19f *** "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 1536: /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 --procedure-- -line- -file--- exec -- _exec 20 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _xCons 37 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tCons 81 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tConsUn 82 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl Token 85 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl include_dir 3 /home/danielb/Desktop/v/cit_parse/src/m3makefile 5 /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args Fatal Error: package build failed Well that was because of the lack of the file PRS.t Searching I noticed that the file is in v/cit_parse/src/PRS.t and made a copy on v/parserlib/ktok/src directory Then try make again and but this time, get this: cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e new source -> compiling PRSTok.m3 "../LINUXLIBC6/PRSTok.m3", line 1: syntax error: missing INTERFACE or MODULE keyword "../LINUXLIBC6/PRSTok.m3", line 1: unable to find interface () "../LINUXLIBC6/PRSTok.m3", line 1: warning: file name (PRSTok.m3) doesn't match module name () 2 errors and 1 warning encountered new source -> compiling PRSTok.i3 new source -> compiling PRSLex.i3 new source -> compiling PRSLex.m3 new source -> compiling PRSParse.i3 new source -> compiling PRSParse.m3 new source -> compiling PRSLexStd.i3 new source -> compiling PRSLexStd.m3 new source -> compiling PRSParseStd.i3 new source -> compiling PRSParseStd.m3 new source -> compiling CHPTok.i3 new source -> compiling CHPTok.m3 "../LINUXLIBC6/CHPTok.m3", line 36: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered new source -> compiling CHPLex.i3 new source -> compiling CHPLex.m3 new source -> compiling CHPParse.i3 new source -> compiling CHPParse.m3 new source -> compiling CHPLexStd.i3 new source -> compiling CHPLexStd.m3 new exporters -> recompiling PRSTok.i3 compilation failed => not building library "libcit_parse.a" Fatal Error: package build failed danielb at danielb-desktop:~/code/caltech-parser/v2/v$ It seems PRSTok.m3 does exist on v/cit_parse/LINUXLIBC6 but is an empty file. Maybe Im not doing the right steps? Thanks --- Mika Nystrom wrote: > Hi again! > > I was able to boot the CVS head of CM3 on my Mac > just fine now, > using the cm3.cfg you sent me. I am still running > the old OS > (Panther, is it?) so I tried doing it the hard way > instead of using > your binaries, and I got something that works pretty > well. Mentor > and Juno work, at least, and that's usually a good > indicator that > one is on the right track... > > But (of course there's a "but"), I am still falling > down on my very > first reported bug, namely this local ktok program. > I still, after > all that you've done, find that it dies on an > illegal instruction > on the Macintosh (I am running 10.3 on a Powerbook). > > The problem goes away if I use either @M3nogc or > @M3noincremental. > The gdb backtrace is not very helpful: it says the > program is > crashing somewhere in a text processing module, > creating an iterator > on a sorted table. > > Sorry to do this but I am feeling a bit clueless, so > if you're > interested and have the time to look into it, I have > set up a minimal > test here: > > http://www.async.caltech.edu/~mika/ktok_example.tgz > > Unfortunately, ktok itself depends on a bunch of > packages. > > To build this, set your CM3 environment variable to > anything (1 > works) and just "make" (GNU make, please). Set the > DEBUGLEVEL > environment variable to "10" for a bit more output > (not much). The > very last step (compiling package cit_parse) fails > for me... > Specifically, the step is: > > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", > line 20: quake runtime error: exit 4: > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > > Looking a bit closer: > > [lapdog:~/t/cit_parse/src] mika% gdb > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri > Jul 16 21:42:28 GMT 2004) > Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 > Starting program: > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > Reading symbols for shared libraries . done > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > > Program received signal EXC_BAD_INSTRUCTION, Illegal > instruction/operand. > 0x00b111c8 in ?? () > (gdb) where > #0 0x00b111c8 in ?? () > #1 0x000120e4 in TextSubs__Apply > (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at > TextSubs.m3:64 > #2 0x0005b15c in RTLinker__RunMainBody > (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 > #3 0x00059f20 in RTLinker__AddUnitI > (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 > #4 0x0005a01c in RTLinker__AddUnit > (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 > #5 0x00001ecc in main (argc=4, argv=0xbffffadc, > envp=0xbffffaf0) at _m3main.mc:4 > (gdb) > > Also: > > PROCEDURE Apply(self: T; src: TEXT): TEXT = > VAR > wr := TextWr.New(); > c: CHAR; > ind, pos, lastFlushed: INTEGER := 0; > textLen := Text.Length(src); > iter: SortedTextTextTbl.Iterator; > original, replacement: TEXT; > key, prefix: TEXT; > PROCEDURE Flush() = > BEGIN > Wr.PutText(wr, Text.Sub(src, lastFlushed, pos > - lastFlushed)); > END Flush; > BEGIN > WHILE pos < textLen DO > c := Text.GetChar(src, pos); > IF c IN self.starts THEN > Debug.Out("analysing: " & Text.Sub(src, > pos), 100); > iter := self.tbl.iterateOrdered(); (* line > 64 *) > ind := pos; > original := ""; > REPEAT > INC(ind); > ... > > I am mystified as to why gdb would say that > RTLinker__RunMainBody > would be calling TextSubs__Apply. > > With @M3nogc or @M3noincremental, all is well... > > I will see if I can figure out more, but this > problem just doesn't > seem to want to go away. To the best of my > knowledge, ktok doesn't > use any UNSAFE code (outside of whatever's in libm3 > of course). > > Mika > > 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 > === message truncated === ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome From dabenavidesd at yahoo.es Wed Jul 4 23:40:34 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 Jul 2007 23:40:34 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Message-ID: <20070704214034.90770.qmail@web27105.mail.ukl.yahoo.com> Sorry the last message was too long and I think was cutted by the mailer. Hi: I take the sources from the your web page and type make on the top of the directory v and end in this message: ===> cit_parse --- building in LINUXLIBC6 --- ignoring override("cit_parse", "/home/danielb/Desktop/v") /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x4000b19f *** "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 1536: /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 --procedure-- -line- -file--- exec -- _exec 20 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _xCons 37 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tCons 81 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tConsUn 82 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl Token 85 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl include_dir 3 /home/danielb/Desktop/v/cit_parse/src/m3makefile 5 /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args Fatal Error: package build failed Well that was because of the lack of the file PRS.t Searching I noticed that the file is in v/cit_parse/src/PRS.t and made a copy on v/parserlib/ktok/src directory Then try make again and but this time, get this: cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e new source -> compiling PRSTok.m3 "../LINUXLIBC6/PRSTok.m3", line 1: syntax error: missing INTERFACE or MODULE keyword "../LINUXLIBC6/PRSTok.m3", line 1: unable to find interface () "../LINUXLIBC6/PRSTok.m3", line 1: warning: file name (PRSTok.m3) doesn't match module name () 2 errors and 1 warning encountered new source -> compiling PRSTok.i3 new source -> compiling PRSLex.i3 new source -> compiling PRSLex.m3 new source -> compiling PRSParse.i3 new source -> compiling PRSParse.m3 new source -> compiling PRSLexStd.i3 new source -> compiling PRSLexStd.m3 new source -> compiling PRSParseStd.i3 new source -> compiling PRSParseStd.m3 new source -> compiling CHPTok.i3 new source -> compiling CHPTok.m3 "../LINUXLIBC6/CHPTok.m3", line 36: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered new source -> compiling CHPLex.i3 new source -> compiling CHPLex.m3 new source -> compiling CHPParse.i3 new source -> compiling CHPParse.m3 new source -> compiling CHPLexStd.i3 new source -> compiling CHPLexStd.m3 new exporters -> recompiling PRSTok.i3 compilation failed => not building library "libcit_parse.a" Fatal Error: package build failed danielb at danielb-desktop:~/code/caltech-parser/v2/v$ It seems PRSTok.m3 does exist on v/cit_parse/LINUXLIBC6 but is an empty file. Maybe Im not doing the right steps? Thanks --- "Daniel Alejandro Benavides D." escribi?: > Hi: > I take the sources from the your web page and type > make on the top of the directory v and end in this > message: > > ===> cit_parse > --- building in LINUXLIBC6 --- > > ignoring override("cit_parse", > "/home/danielb/Desktop/v") > > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to > dereference NIL > *** pc = 0x4000b19f > *** > > "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", > line 20: quake runtime error: exit 1536: > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 20 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _xCons 37 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _tCons 81 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _tConsUn 82 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > Token 85 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > include_dir 3 > /home/danielb/Desktop/v/cit_parse/src/m3makefile > 5 > /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > > Well that was because of the lack of the file PRS.t > > Searching I noticed that the file is in > v/cit_parse/src/PRS.t and made a copy on > v/parserlib/ktok/src directory > Then try make again and but this time, get this: > > cp > /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome From mika at async.caltech.edu Thu Jul 5 14:48:46 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 05 Jul 2007 05:48:46 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Wed, 04 Jul 2007 23:35:13 +0200." <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Message-ID: <200707051248.l65Cmk7b064556@camembert.async.caltech.edu> Hi Daniel, Thanks for helping look into this. Could you send me a gdb stack trace or something along those lines of the segmentation violation? It doesn't have to be m3gdb, normal gdb would do fine. The PRS.t file isn't missing. What you're seeing is ktok being run with a CWD of /home/danielb/Desktop/v/cit_parse/LINUXLIBC6 , so PRS.t is indeed "../src/PRS.t". The reason the file is empty in the last example is that that's what had been generated by the time the ktok program crashed. That's exactly what I get on my Mac, except the program crashes on an illegal instruction, not a segfault. Of course it works fine on PM3, both Windows and Unix, and older versions of CM3... I'm sure there's some kind of bug in ktok, too. Mika "Daniel Alejandro Benavides D." writes: >Hi: >I take the sources from the your web page and type >make on the top of the directory v and end in this >message: > >===> cit_parse >--- building in LINUXLIBC6 --- > >ignoring override("cit_parse", >"/home/danielb/Desktop/v") > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to >dereference NIL >*** pc = 0x4000b19f >*** > >"/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", >line 20: quake runtime error: exit 1536: >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 > >--procedure-- -line- -file--- >exec -- >_exec 20 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_xCons 37 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_tCons 81 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_tConsUn 82 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >Token 85 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >include_dir 3 >/home/danielb/Desktop/v/cit_parse/src/m3makefile > 5 >/home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > >Fatal Error: package build failed > >Well that was because of the lack of the file PRS.t > >Searching I noticed that the file is in >v/cit_parse/src/PRS.t and made a copy on >v/parserlib/ktok/src directory >Then try make again and but this time, get this: > >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y >. >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext >../src/CHPLexStd.e >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext >../src/CHPLexStd.e >new source -> compiling PRSTok.m3 >"../LINUXLIBC6/PRSTok.m3", line 1: syntax error: >missing INTERFACE or MODULE keyword >"../LINUXLIBC6/PRSTok.m3", line 1: unable to find >interface () >"../LINUXLIBC6/PRSTok.m3", line 1: warning: file name >(PRSTok.m3) doesn't match module name () >2 errors and 1 warning encountered >new source -> compiling PRSTok.i3 >new source -> compiling PRSLex.i3 >new source -> compiling PRSLex.m3 >new source -> compiling PRSParse.i3 >new source -> compiling PRSParse.m3 >new source -> compiling PRSLexStd.i3 >new source -> compiling PRSLexStd.m3 >new source -> compiling PRSParseStd.i3 >new source -> compiling PRSParseStd.m3 >new source -> compiling CHPTok.i3 >new source -> compiling CHPTok.m3 >"../LINUXLIBC6/CHPTok.m3", line 36: warning: >potentially unhandled exception: >RTAllocator.OutOfMemory >1 warning encountered >new source -> compiling CHPLex.i3 >new source -> compiling CHPLex.m3 >new source -> compiling CHPParse.i3 >new source -> compiling CHPParse.m3 >new source -> compiling CHPLexStd.i3 >new source -> compiling CHPLexStd.m3 >new exporters -> recompiling PRSTok.i3 >compilation failed => not building library >"libcit_parse.a" >Fatal Error: package build failed > >danielb at danielb-desktop:~/code/caltech-parser/v2/v$ > > >It seems PRSTok.m3 does exist on >v/cit_parse/LINUXLIBC6 but is an empty file. > >Maybe Im not doing the right steps? > >Thanks > > > > >--- Mika Nystrom wrote: > >> Hi again! >> >> I was able to boot the CVS head of CM3 on my Mac >> just fine now, >> using the cm3.cfg you sent me. I am still running >> the old OS >> (Panther, is it?) so I tried doing it the hard way >> instead of using >> your binaries, and I got something that works pretty >> well. Mentor >> and Juno work, at least, and that's usually a good >> indicator that >> one is on the right track... >> >> But (of course there's a "but"), I am still falling >> down on my very >> first reported bug, namely this local ktok program. >> I still, after >> all that you've done, find that it dies on an >> illegal instruction >> on the Macintosh (I am running 10.3 on a Powerbook). >> >> The problem goes away if I use either @M3nogc or >> @M3noincremental. >> The gdb backtrace is not very helpful: it says the >> program is >> crashing somewhere in a text processing module, >> creating an iterator >> on a sorted table. >> >> Sorry to do this but I am feeling a bit clueless, so >> if you're >> interested and have the time to look into it, I have >> set up a minimal >> test here: >> >> http://www.async.caltech.edu/~mika/ktok_example.tgz >> >> Unfortunately, ktok itself depends on a bunch of >> packages. >> >> To build this, set your CM3 environment variable to >> anything (1 >> works) and just "make" (GNU make, please). Set the >> DEBUGLEVEL >> environment variable to "10" for a bit more output >> (not much). The >> very last step (compiling package cit_parse) fails >> for me... >> Specifically, the step is: >> >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> WELCOME! >> GOT TOKPARAMS! >> GOT TOKENS >> GOT SUBS! >> "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", >> line 20: quake runtime error: exit 4: >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> >> Looking a bit closer: >> >> [lapdog:~/t/cit_parse/src] mika% gdb >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri >> Jul 16 21:42:28 GMT 2004) >> Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 >> Starting program: >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> Reading symbols for shared libraries . done >> WELCOME! >> GOT TOKPARAMS! >> GOT TOKENS >> GOT SUBS! >> >> Program received signal EXC_BAD_INSTRUCTION, Illegal >> instruction/operand. >> 0x00b111c8 in ?? () >> (gdb) where >> #0 0x00b111c8 in ?? () >> #1 0x000120e4 in TextSubs__Apply >> (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at >> TextSubs.m3:64 >> #2 0x0005b15c in RTLinker__RunMainBody >> (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 >> #3 0x00059f20 in RTLinker__AddUnitI >> (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 >> #4 0x0005a01c in RTLinker__AddUnit >> (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 >> #5 0x00001ecc in main (argc=4, argv=0xbffffadc, >> envp=0xbffffaf0) at _m3main.mc:4 >> (gdb) >> >> Also: >> >> PROCEDURE Apply(self: T; src: TEXT): TEXT = >> VAR >> wr := TextWr.New(); >> c: CHAR; >> ind, pos, lastFlushed: INTEGER := 0; >> textLen := Text.Length(src); >> iter: SortedTextTextTbl.Iterator; >> original, replacement: TEXT; >> key, prefix: TEXT; >> PROCEDURE Flush() = >> BEGIN >> Wr.PutText(wr, Text.Sub(src, lastFlushed, pos >> - lastFlushed)); >> END Flush; >> BEGIN >> WHILE pos < textLen DO >> c := Text.GetChar(src, pos); >> IF c IN self.starts THEN >> Debug.Out("analysing: " & Text.Sub(src, >> pos), 100); >> iter := self.tbl.iterateOrdered(); (* line >> 64 *) >> ind := pos; >> original := ""; >> REPEAT >> INC(ind); >> ... >> >> I am mystified as to why gdb would say that >> RTLinker__RunMainBody >> would be calling TextSubs__Apply. >> >> With @M3nogc or @M3noincremental, all is well... >> >> I will see if I can figure out more, but this >> problem just doesn't >> seem to want to go away. To the best of my >> knowledge, ktok doesn't >> use any UNSAFE code (outside of whatever's in libm3 >> of course). >> >> Mika >> >> 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 >> >=== message truncated === > > > > >____________________________________________________________________________________ >?Descubre una nueva forma de obtener respuestas a tus preguntas! >Entra en Yahoo! Respuestas. >http://es.answers.yahoo.com/info/welcome From rodney.bates at wichita.edu Thu Jul 5 15:35:31 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 05 Jul 2007 08:35:31 -0500 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468CF3A3.2090707@wichita.edu> Could you make your replacement setjmp/longjmp available for those of us who are still maintaining old PM3 implementations? This would be a great help. Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Thu Jul 5 20:46:21 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 5 Jul 2007 20:46:21 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707051248.l65Cmk7b064556@camembert.async.caltech.edu> Message-ID: <20070705184621.73160.qmail@web27113.mail.ukl.yahoo.com> Hi Mika: What I get here executing is sometimes an Illegal intruction or Floating point exception (I guess OS message when executing the program) or the CM3 runtime error message. Well I debugged a time and I got it breaks inside RTType.m3, but m3gdb process ends, besides the tok process. (m3gdb) where #0 FindType (id=995871772) at RTType.m3:137 #1 0x0809afb6 in ScanTypecase (ref=16_b7eeb0cc, x=16_0815d844) at RTType.m3:123 #2 0x080b2bdf in Sub (t=16_b7eeb0cc, start=0, length=10) at TextSub.m3:35 #3 0x0804a6ba in Base (t=16_b7eeb0cc, suffix=16_081397a8) at TokParams.m3:22 #4 0x0804a700 in SetBaseFrom (t=16_b7eeb0cc, suffix=16_081397a8) at TokParams.m3:40 #5 0x0804ab74 in Get (progName=16_08139798, inSuffix=16_081397a8, outSuffix=16_081397b8, specifyTok=FALSE, _result= RECORD source = NIL; out = NIL; tokSource = NIL; tokOut = NIL; outBase = NIL; tokOutBase = NIL; END) at TokParams.m3:63 #6 0x08049011 in Main (mode=1) at Main.m3:92 #7 0x080949d9 in RunMainBody (m=16_081504e0) at RTLinker.m3:399 #8 0x0809347e in AddUnitI (m=16_081504e0) at RTLinker.m3:113 #9 0x08093507 in AddUnit (b={"Main_M3", Declared at: Main.m3:90}) at RTLinker.m3:122 #10 0x08048217 in main (argc=4, argv=0xbf921b64, envp=0xbf921b78) at _m3main.mc:4 (m3gdb) step FindType (id=4) at RTType.m3:138 138 in RTType.m3 (m3gdb) step Segmentation fault danielb at danielb-desktop:~/code/caltech-parser/v/cit_parse/LINUXLIBC6$ *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xb7eef1e7 *** danielb at danielb-desktop:~/code/caltech-parser/v/cit_parse/LINUXLIBC6$ Any more helpful? Bye --- Mika Nystrom wrote: > Hi Daniel, > > Thanks for helping look into this. Could you send > me a gdb stack > trace or something along those lines of the > segmentation violation? > It doesn't have to be m3gdb, normal gdb would do > fine. > > The PRS.t file isn't missing. What you're seeing is > ktok being run > with a CWD of > /home/danielb/Desktop/v/cit_parse/LINUXLIBC6 , so > PRS.t is indeed "../src/PRS.t". > > The reason the file is empty in the last example is > that that's > what had been generated by the time the ktok program > crashed. That's > exactly what I get on my Mac, except the program > crashes on an > illegal instruction, not a segfault. Of course it > works fine on > PM3, both Windows and Unix, and older versions of > CM3... I'm sure > there's some kind of bug in ktok, too. > > Mika > > > > "Daniel Alejandro Benavides D." writes: > >Hi: > >I take the sources from the your web page and type > >make on the top of the directory v and end in this > >message: > > > >===> cit_parse > >--- building in LINUXLIBC6 --- > > > >ignoring override("cit_parse", > >"/home/danielb/Desktop/v") > > > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > > > > > >*** > >*** runtime error: > >*** Segmentation violation - possible attempt to > >dereference NIL > >*** pc = 0x4000b19f > >*** > > > >"/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", > >line 20: quake runtime error: exit 1536: > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > > > >--procedure-- -line- -file--- > >exec -- > >_exec 20 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_xCons 37 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_tCons 81 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_tConsUn 82 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >Token 85 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >include_dir 3 > >/home/danielb/Desktop/v/cit_parse/src/m3makefile > > 5 > >/home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > > > >Fatal Error: package build failed > > > >Well that was because of the lack of the file PRS.t > > > >Searching I noticed that the file is in > >v/cit_parse/src/PRS.t and made a copy on > >v/parserlib/ktok/src directory > >Then try make again and but this time, get this: > > > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y > >. > >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext > >../src/CHPLexStd.e > >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext > >../src/CHPLexStd.e > >new source -> compiling PRSTok.m3 > >"../LINUXLIBC6/PRSTok.m3", line 1: syntax error: > >missing INTERFACE or MODULE keyword > >"../LINUXLIBC6/PRSTok.m3", line 1: unable to find > >interface () > >"../LINUXLIBC6/PRSTok.m3", line 1: warning: file > name > >(PRSTok.m3) doesn't match module name ( id>) > >2 errors and 1 warning encountered > >new source -> compiling PRSTok.i3 > >new source -> compiling PRSLex.i3 > >new source -> compiling PRSLex.m3 > >new source -> compiling PRSParse.i3 > >new source -> compiling PRSParse.m3 > >new source -> compiling PRSLexStd.i3 > >new source -> compiling PRSLexStd.m3 > >new source -> compiling PRSParseStd.i3 > >new source -> compiling PRSParseStd.m3 > >new source -> compiling CHPTok.i3 > >new source -> compiling CHPTok.m3 > >"../LINUXLIBC6/CHPTok.m3", line 36: warning: > >potentially unhandled exception: > >RTAllocator.OutOfMemory > >1 warning encountered > >new source -> compiling CHPLex.i3 > >new source -> compiling CHPLex.m3 > >new source -> compiling CHPParse.i3 > >new source -> compiling CHPParse.m3 > >new source -> compiling CHPLexStd.i3 > >new source -> compiling CHPLexStd.m3 > >new exporters -> recompiling PRSTok.i3 > >compilation failed => not building library > >"libcit_parse.a" > >Fatal Error: package build failed > > > >danielb at danielb-desktop:~/code/caltech-parser/v2/v$ > > > > > > >It seems PRSTok.m3 does exist on > >v/cit_parse/LINUXLIBC6 but is an empty file. > > > >Maybe Im not doing the right steps? > > > >Thanks > > > > > > > > > >--- Mika Nystrom wrote: > > > >> Hi again! > >> > >> I was able to boot the CVS head of CM3 on my Mac > >> just fine now, > >> using the cm3.cfg you sent me. I am still > running > >> the old OS > >> (Panther, is it?) so I tried doing it the hard > way > >> instead of using > >> your binaries, and I got something that works > pretty > >> well. Mentor > >> and Juno work, at least, and that's usually a > good > >> indicator that > >> one is on the right track... > >> > >> But (of course there's a "but"), I am still > falling > >> down on my very > >> first reported bug, namely this local ktok > program. > >> I still, after > >> all that you've done, find that it dies on an > >> illegal instruction > >> on the Macintosh (I am running 10.3 on a > Powerbook). > >> > >> The problem goes away if I use either @M3nogc or > >> @M3noincremental. > >> The gdb backtrace is not very helpful: it says > the > >> program is > >> crashing somewhere in a text processing module, > >> creating an iterator > >> on a sorted table. > >> > >> Sorry to do this but I am feeling a bit clueless, > so > === message truncated === ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From dragisha at m3w.org Tue Jul 10 22:46:40 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 10 Jul 2007 22:46:40 +0200 Subject: [M3devel] revevrsed EXTERNAL, almotht :) Message-ID: <1184100400.29933.3.camel@faramir.m3w.org> Can I make Modula-3 procedure, or even better - Main_M3 to be called other than that in object code? -- Dragi?a Duri? From lemming at henning-thielemann.de Wed Jul 11 13:49:34 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Jul 2007 13:49:34 +0200 (MEST) Subject: [M3devel] revevrsed EXTERNAL, almotht :) In-Reply-To: <1184100400.29933.3.camel@faramir.m3w.org> References: <1184100400.29933.3.camel@faramir.m3w.org> Message-ID: On Tue, 10 Jul 2007, [UTF-8] Dragi??a Duri?^G wrote: > Can I make Modula-3 procedure, or even better - Main_M3 to be called > other than that in object code? Do you mean the CALLBACK pragma? From dragisha at m3w.org Wed Jul 11 18:02:34 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 11 Jul 2007 18:02:34 +0200 Subject: [M3devel] revevrsed EXTERNAL, almotht :) In-Reply-To: References: <1184100400.29933.3.camel@faramir.m3w.org> Message-ID: <1184169754.2424.4.camel@faramir.m3w.org> I think not. What I need for Modula-3 program to be loaded (ie initialized) as a .so is true C procedure entry point, trivial to write in C so there is no need to force CM3 to make one of Modula-3 procedures known by "external" name. Standard _m3main execution flow has to be split in two parts and executed from this C "stub". Calling conventions are possible another problem. I don't think there would be one under *nix, and for Windows - it's a todo :). On Wed, 2007-07-11 at 13:49 +0200, Henning Thielemann wrote: > On Tue, 10 Jul 2007, [UTF-8] Dragi?a Duri^G wrote: > > > Can I make Modula-3 procedure, or even better - Main_M3 to be called > > other than that in object code? > > Do you mean the CALLBACK pragma? -- Dragi?a Duri? From wagner at elegosoft.com Fri Jul 13 09:33:58 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jul 2007 09:33:58 +0200 (CEST) Subject: [M3devel] http://llvm.org/ as M3 backend; was: Re: Why? In-Reply-To: <12678.1184263773@sa.vix.com> References: <0W2kg.46558$4L1.20223@newssvr11.news.prodigy.com> <87mzcft02e.fsf@thalassa.informatimago.com> <4foappF1k1snbU1@individual.net> <4gde82F1lsi14U1@individual.net> <4gh9gfF1neuiuU1@individual.net> <4grqp3F1obofbU1@individual.net> <12678.1184263773@sa.vix.com> Message-ID: <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> On Thu, July 12, 2007 20:09, Paul Vixie wrote: > has anyone investigated http://llvm.org/ as a potential new M3 backend? I don't think so, but the first paragraphs on the front page sound promising. I'll cc this to the m3devel list to see if anybody knows more or is interested. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Jul 13 17:43:01 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 13 Jul 2007 10:43:01 -0500 Subject: [M3devel] CVS deprecated info strings? Message-ID: <46979D85.3060001@wichita.edu> I just got this message from CVS: cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. I am guessing this refers to stylized comments in the file(s) I committed. Any pointers to documentation on what CVS really wants here? The files are all part of m3gdb, and no doubt contain things from very long ago. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jdp at polstra.com Fri Jul 13 17:51:31 2007 From: jdp at polstra.com (John Polstra) Date: Fri, 13 Jul 2007 08:51:31 -0700 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <46979F83.4070301@polstra.com> Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts > to use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. > Any pointers to documentation on what CVS really wants here? The files are > all part of m3gdb, and no doubt contain things from very long ago. I'm just guessing, but this sounds more like a complaint from the perl scripts in the repository's CVSROOT directory. Maybe somebody updated the perl installation on the repository host, deprecating some feature that the scripts use. John From hosking at cs.purdue.edu Fri Jul 13 18:05:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 13 Jul 2007 12:05:28 -0400 Subject: [M3devel] http://llvm.org/ as M3 backend; was: Re: Why? In-Reply-To: <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> References: <0W2kg.46558$4L1.20223@newssvr11.news.prodigy.com> <87mzcft02e.fsf@thalassa.informatimago.com> <4foappF1k1snbU1@individual.net> <4gde82F1lsi14U1@individual.net> <4gh9gfF1neuiuU1@individual.net> <4grqp3F1obofbU1@individual.net> <12678.1184263773@sa.vix.com> <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> Message-ID: <099535B8-2C0A-4345-BF35-CBA02EC75F2C@cs.purdue.edu> I've had a little contact with some of the llvm team re M3, but forget now who that was. Certainly, I think it would be fun to do an M3CG->LLVM backend. On Jul 13, 2007, at 3:33 AM, Olaf Wagner wrote: > On Thu, July 12, 2007 20:09, Paul Vixie wrote: >> has anyone investigated http://llvm.org/ as a potential new M3 >> backend? > > I don't think so, but the first paragraphs on the front page sound > promising. I'll cc this to the m3devel list to see if anybody knows > more or is interested. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 > Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From stsp at elego.de Fri Jul 13 18:15:15 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 13 Jul 2007 18:15:15 +0200 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <20070713161515.GC98227@ted.stsp.lan> On Fri, Jul 13, 2007 at 10:43:01AM -0500, Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts to > use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. No. It's a known issue. > Any pointers to documentation on what CVS really wants here? http://ximbiot.com/cvs/manual/cvs-1.12.6/cvs_18.html#SEC168 -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mika at async.caltech.edu Mon Jul 16 03:53:11 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 18:53:11 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Mon, 02 Jul 2007 11:03:42 EDT." Message-ID: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> 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! 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 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? From hosking at cs.purdue.edu Mon Jul 16 05:39:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Jul 2007 23:39:26 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> References: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> Message-ID: <9E796D22-3940-4FB8-9B5B-F17D4648DF56@cs.purdue.edu> 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! > > 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"))); Where does the variable 'wr' come from? It is this 'wr' that is failing the assert. It should not be gray, assuming that the GC was able to find it. Can I see your Main.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 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? From hosking at cs.purdue.edu Mon Jul 16 05:41:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Jul 2007 23:41:31 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> References: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> Message-ID: 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 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? From mika at async.caltech.edu Mon Jul 16 05:51:33 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 20:51:33 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Sun, 15 Jul 2007 23:39:26 EDT." <9E796D22-3940-4FB8-9B5B-F17D4648DF56@cs.purdue.edu> Message-ID: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> Tony Hosking writes: ... >> >> Line 113 in Main.m3 is: >> >> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); > >Where does the variable 'wr' come from? It is this 'wr' that is >failing the assert. It should not be gray, assuming that the GC was >able to find it. Can I see your Main.m3? > It fails exactly the same way with @M3paranoidgc. wr comes from FileWr.Open. The programmer has re-used wr for two open FileWrs... I marked line 113, where it crashes: (* Copyright (c) 2000 California Institute of Technology *) (* All rights reserved. See the file COPYRIGHT for a full description. *) (* $Id: Main.m3,v 1.3 2002/12/11 08:54:53 kp Exp $ *) MODULE Main; IMPORT Debug; IMPORT tokformBundle, Bundle; IMPORT TokParams; IMPORT TokSpec; IMPORT FileWr, Wr, Thread, OSError; IMPORT TextWr; IMPORT TextSubs; IMPORT TextList; IMPORT Pathname; IMPORT Fmt; IMPORT FmtTable; (* IMPORT Term; *) <* FATAL Thread.Alerted, Wr.Failure *> VAR Form := tokformBundle.Get(); PROCEDURE FormatTypes(t: TextList.T; tokName, kind: TEXT): TEXT = VAR wr := TextWr.New(); cur := t; subs: TextSubs.T; BEGIN WHILE cur # NIL DO subs := NEW(TextSubs.T).init(); subs.add("%type", cur.head); subs.add("%tok", tokName); Wr.PutText(wr, subs.apply(Bundle.Get(Form, kind))); cur := cur.tail; END; RETURN TextWr.ToText(wr); END FormatTypes; PROCEDURE FormatLegalConst(tok: TokSpec.T): TEXT = VAR dummy: TEXT; fmt := NEW(FmtTable.T).init(); BEGIN FOR i := 1 TO tok.lastConstCode DO IF tok.constTokensR.get(i, dummy) THEN fmt.putInt(i); END; END; RETURN fmt.toText(); END FormatLegalConst; PROCEDURE FormatNamedConst(tok: TokSpec.T): TEXT = VAR cur := tok.tokens; name: TEXT; code: INTEGER; wr := TextWr.New(); BEGIN WHILE cur # NIL DO name := cur.head; IF tok.constTokens.get(name, code) THEN Wr.PutText(wr, " " & name & " = " & Fmt.Int(code) & ";\n"); END; cur := cur.tail; END; RETURN TextWr.ToText(wr); END FormatNamedConst; PROCEDURE Subs(tok: TokSpec.T; name: TEXT): TextSubs.T = VAR subs := NEW(TextSubs.T).init(); BEGIN subs.add("\\\n", ""); subs.add("%tok", name); subs.add("%type", FormatTypes(tok.varTokens, name, "tokform.type")); subs.add("%case", FormatTypes(tok.varTokens, name, "tokform.case")); subs.add("%constSet", FormatLegalConst(tok)); subs.add("%constName", FormatNamedConst(tok)); subs.add("%lastConst", Fmt.Int(tok.lastConstCode)); subs.add("%gen", "(* Generated by ktok *)"); RETURN subs; END Subs; VAR tp: TokParams.T; tok: TokSpec.T; subs: TextSubs.T; wr: Wr.T; BEGIN Debug.S("WELCOME!"); tp := TokParams.Get("tok", ".t", "Tok.i3", FALSE); Debug.S("GOT TOKPARAMS!"); tok := TokParams.ReadTokens(tp); Debug.S("GOT TOKENS"); subs := Subs(tok, tp.outBase); Debug.S("GOT SUBS!"); TRY wr := FileWr.Open(tp.out); EXCEPT OSError.E => Debug.Error("Cannot open tok interface output file: " & tp.out); END; Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.i3"))); Wr.Close(wr); TRY wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3")); EXCEPT OSError.E => Debug.Error("Cannot open tok implementation output file: " & Pathname.ReplaceExt(tp.out, "m3")); END; Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); (* line 113 *) Wr.Close(wr); END Main. From mika at async.caltech.edu Mon Jul 16 06:50:52 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 21:50:52 -0700 Subject: [M3devel] User-level threading In-Reply-To: Your message of "Wed, 04 Jul 2007 22:25:16 +0200." <20070704202516.GA26977@elegosoft.com> Message-ID: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Olaf Wagner writes: >On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: >> In looking at things again, I am more and more convinced that >> ThreadPosix should be implemented against the standard API for >> makecontext/getcontext/setcontext/swapcontext. Platforms that do not >> provide these will need to provide an equivalent implementation of >> these routines, similar to what you suggest. Right now, I know all of >> SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary >> support. > >I think a `standard' implementation using makecontext/getcontext/... >would be the best. For those platforms that do not support that, >we can still use a C or assembler implementation. > >I would strongly vote for keeping user-level threading, too. Wouldn't the ideal be to have a mixed system, where N user-level threads run inside M <= N, M \approx NCPUS Pthreads? Anyone who thinks user-level threads are unnecessary should try the following program, which runs just fine under user-level threads on FreeBSD, and locks up horrendously after running about 4% of the way on Darwin/Pthreads... Mika MODULE Main; IMPORT Thread; IMPORT Rd, Stdio, Wr, Random, Fmt; TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; PROCEDURE A(cl : Cl) : REFANY = VAR rand := NEW(Random.Default).init(); BEGIN LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText(Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END END A; CONST Nthreads=10000; BEGIN FOR i := 1 TO Nthreads DO Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush(Stdio.stdout); EVAL Thread.Fork(NEW(Cl)) END; LOOP WITH c = Rd.GetChar(Stdio.stdin) DO IF c = 'q' THEN EXIT END END END END Main. > >Olaf >-- >Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 >http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Mon Jul 16 08:27:36 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 23:27:36 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Sun, 15 Jul 2007 23:41:31 EDT." Message-ID: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 16 14:42:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:42:43 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> References: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> Message-ID: <4612CAB0-02E4-4D53-AF6F-B05C1972296E@cs.purdue.edu> I'll need to run this in the debugger. Do your previous instructions for download and build still hold true? On Jul 15, 2007, at 11:51 PM, Mika Nystrom wrote: > Tony Hosking writes: > ... >>> >>> Line 113 in Main.m3 is: >>> >>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); >> >> Where does the variable 'wr' come from? It is this 'wr' that is >> failing the assert. It should not be gray, assuming that the GC was >> able to find it. Can I see your Main.m3? >> > > It fails exactly the same way with @M3paranoidgc. > > wr comes from FileWr.Open. The programmer has re-used wr for two > open FileWrs... I marked line 113, where it crashes: > > (* Copyright (c) 2000 California Institute of Technology *) > (* All rights reserved. See the file COPYRIGHT for a full > description. *) > (* $Id: Main.m3,v 1.3 2002/12/11 08:54:53 kp Exp $ *) > > MODULE Main; > IMPORT Debug; > IMPORT tokformBundle, Bundle; > IMPORT TokParams; > IMPORT TokSpec; > IMPORT FileWr, Wr, Thread, OSError; > IMPORT TextWr; > IMPORT TextSubs; > IMPORT TextList; > IMPORT Pathname; > IMPORT Fmt; > IMPORT FmtTable; > (* IMPORT Term; *) > <* FATAL Thread.Alerted, Wr.Failure *> > > VAR > Form := tokformBundle.Get(); > > PROCEDURE FormatTypes(t: TextList.T; tokName, kind: TEXT): TEXT = > VAR > wr := TextWr.New(); > cur := t; > subs: TextSubs.T; > BEGIN > WHILE cur # NIL DO > subs := NEW(TextSubs.T).init(); > subs.add("%type", cur.head); > subs.add("%tok", tokName); > Wr.PutText(wr, subs.apply(Bundle.Get(Form, kind))); > cur := cur.tail; > END; > RETURN TextWr.ToText(wr); > END FormatTypes; > > PROCEDURE FormatLegalConst(tok: TokSpec.T): TEXT = > VAR > dummy: TEXT; > fmt := NEW(FmtTable.T).init(); > BEGIN > FOR i := 1 TO tok.lastConstCode DO > IF tok.constTokensR.get(i, dummy) THEN > fmt.putInt(i); > END; > END; > RETURN fmt.toText(); > END FormatLegalConst; > > PROCEDURE FormatNamedConst(tok: TokSpec.T): TEXT = > VAR > cur := tok.tokens; > name: TEXT; > code: INTEGER; > wr := TextWr.New(); > BEGIN > WHILE cur # NIL DO > name := cur.head; > IF tok.constTokens.get(name, code) THEN > Wr.PutText(wr, " " & name & " = " & Fmt.Int(code) & ";\n"); > END; > cur := cur.tail; > END; > RETURN TextWr.ToText(wr); > END FormatNamedConst; > > PROCEDURE Subs(tok: TokSpec.T; name: TEXT): TextSubs.T = > VAR > subs := NEW(TextSubs.T).init(); > BEGIN > subs.add("\\\n", ""); > subs.add("%tok", name); > subs.add("%type", FormatTypes(tok.varTokens, name, > "tokform.type")); > subs.add("%case", FormatTypes(tok.varTokens, name, > "tokform.case")); > subs.add("%constSet", FormatLegalConst(tok)); > subs.add("%constName", FormatNamedConst(tok)); > subs.add("%lastConst", Fmt.Int(tok.lastConstCode)); > subs.add("%gen", "(* Generated by ktok *)"); > RETURN subs; > END Subs; > > > VAR > tp: TokParams.T; > tok: TokSpec.T; > subs: TextSubs.T; > wr: Wr.T; > BEGIN > Debug.S("WELCOME!"); > tp := TokParams.Get("tok", ".t", "Tok.i3", FALSE); > Debug.S("GOT TOKPARAMS!"); > tok := TokParams.ReadTokens(tp); > Debug.S("GOT TOKENS"); > subs := Subs(tok, tp.outBase); > Debug.S("GOT SUBS!"); > TRY > wr := FileWr.Open(tp.out); > EXCEPT OSError.E => > Debug.Error("Cannot open tok interface output file: " & tp.out); > END; > > Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.i3"))); > Wr.Close(wr); > > TRY > wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3")); > EXCEPT OSError.E => > Debug.Error("Cannot open tok implementation output file: " & > Pathname.ReplaceExt(tp.out, "m3")); > END; > Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); (* > line 113 *) > Wr.Close(wr); > END Main. > From hosking at cs.purdue.edu Mon Jul 16 14:47:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:47:08 -0400 Subject: [M3devel] User-level threading In-Reply-To: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> References: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Message-ID: <319398F1-B01D-4E75-BBDA-AD31D9E951D4@cs.purdue.edu> Mixed systems are difficult to get working properly (because of interactions between system and user scheduling), and usually result in more trouble than they are worth (witness discussions on this subject regarding Jikes RVM). The difficulties are particularly pronounced with preemptive scheduling where system thread switches can occur at any time. My inclination is to implement the user-level threading properly using setcontext, etc., instead of setjmp/ longjmp. I will probably get to this next on my list of tinkering tasks with CM3. Right now, I want to finish off my LONGINT implementation (grappling with the compiler as we speak) as well as the GC issue you reported. On Jul 16, 2007, at 12:50 AM, Mika Nystrom wrote: > Olaf Wagner writes: >> On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: >>> In looking at things again, I am more and more convinced that >>> ThreadPosix should be implemented against the standard API for >>> makecontext/getcontext/setcontext/swapcontext. Platforms that do >>> not >>> provide these will need to provide an equivalent implementation of >>> these routines, similar to what you suggest. Right now, I know >>> all of >>> SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary >>> support. >> >> I think a `standard' implementation using makecontext/getcontext/... >> would be the best. For those platforms that do not support that, >> we can still use a C or assembler implementation. >> >> I would strongly vote for keeping user-level threading, too. > > Wouldn't the ideal be to have a mixed system, where N user-level > threads > run inside M <= N, M \approx NCPUS Pthreads? > > Anyone who thinks user-level threads are unnecessary should try the > following program, which runs just fine under user-level threads > on FreeBSD, and locks up horrendously after running about 4% of the > way on Darwin/Pthreads... > > Mika > > MODULE Main; > IMPORT Thread; > IMPORT Rd, Stdio, Wr, Random, Fmt; > > TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; > > > PROCEDURE A(cl : Cl) : REFANY = > VAR rand := NEW(Random.Default).init(); > BEGIN > LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText > (Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END > END A; > > CONST Nthreads=10000; > BEGIN > FOR i := 1 TO Nthreads DO > Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush > (Stdio.stdout); > EVAL Thread.Fork(NEW(Cl)) > END; > > LOOP > WITH c = Rd.GetChar(Stdio.stdin) DO > IF c = 'q' THEN EXIT END > END > END > END Main. > >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 >> Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 >> 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >> Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 From hosking at cs.purdue.edu Mon Jul 16 14:51:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:51:06 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: On Jul 16, 2007, at 2:27 AM, Mika Nystrom wrote: > An update: > > I was able to get everything to build by using @M3noincremental. Yes, this makes sense, since the error is one that can only occur with incremental GC. > > I am still running into a few errors when trying to run things. > So far, most problems seem to be traceable back to a garbage > collection > problem. @M3noincremental helps, but doesn't solve all GC-related > issues. > > The errors I seem to be running into are... > > 1. Some kind of memory protection error when I am reading pickles > from files. Haven't looked at this in detail yet. Odd. Please fill me in. > 2. The assert when spawning threads in mentor, mentioned earlier. I've not seen this since the fix I made a few weeks ago. It was related to weak references. > 3. Various sinks of processor time when running multithreaded things. > > The program I sent earlier to illustrate the (in)efficiency of > threading was an attempt to isolate some of the issues under 3., but > that simple program didn't seem to tickle any bugs. Instead, I have > an Othello program that does. It uses Trestle, X, etc., and you can > get it (via the references on the Wikipedia m3 page, actually: it > was originally part of an assignment for a class I was teaching at > Caltech). Cool. Another bug to chase. > What happens is this... everything seems functionally correct, but > after a while, the program, for no apparent reason at all, starts > to take 100% of the CPU. I think there may be several bugs. I have > been able to get programs to slow down and threads to stop running. I'd appreciate any hints you can give. What platform? Possibly related to thread stopping/restarting. > To the description: my othello program opens up a VBT and calls a > Thread.Join. This puts it in ThreadPThread.InnerWait, and there > all seems OK. The running thread (or one of them) calls Trestle.Ping, > which calls Thread.Pause. For a few seconds all is OK, the mouse > pointer is tracked, repaints work, etc. But after a while, the > program goes haywire. What happens is that the program is still > functionally correct, as before, but it starts to eat 100% CPU. > Looking a little closer, Thread.Pause has died, or is at least badly > wounded. It simply doesn't yield the CPU. > > I changed ThreadPThread.Pause to the following: > > PROCEDURE Pause(n: LONGREAL) = > VAR > amount, remaining: Utime.struct_timespec; > self := Self(); > BEGIN > IF self = NIL THEN Die(ThisLine(), "Pause called from a non- > Modula-3 thread") END; > IF n <= 0.0d0 THEN RETURN END; > IF perfOn THEN PerfChanged(self.id, State.pausing) END; > ToNTime(n, amount); > <* ASSERT amount.tv_sec >= 0 *> > > RTIO.PutChar('f'); RTIO.Flush(); > LOOP > RTIO.PutChar('b'); RTIO.Flush(); > <* ASSERT amount.tv_sec >= 0 *> (* line 756 *) > RTIO.PutChar('a'); RTIO.Flush(); > WITH nr = Utime.nanosleep(amount, remaining) DO > IF nr = 0 THEN > RTIO.PutChar('!'); RTIO.Flush(); > EXIT > ELSE > RTIO.PutChar('.'); RTIO.Flush(); > VAR > as := amount.tv_sec; > an := amount.tv_nsec; > rs := remaining.tv_sec; > rn := remaining.tv_nsec; > BEGIN > amount := remaining; > END > END > END > END; > IF perfOn THEN PerfChanged(self.id, State.alive) END; > END Pause; > > Ironically, the change seems to make the program slightly > less susceptible to trouble, but it still happens. The end result of > running my program is not terribly helpful: > > Repaint! > .ba.b > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 756 > *** That doesn't mesh with the latest version of ThreadPThread.m3. Are you sure you are up to date? > > > Program exited with code 01. > (gdb) where > No stack. > > Note that line 756 is after the arguments to nanosleep have already > been checked. The tv_secs gets set to -1... and nanosleep returns > right away. But nanosleep declares its first argument as const *, > so it's not nanosleep itself that's clobbering it. > > XXX > XXX The problem goes away with @M3nogc. This problem does NOT > XXX go away with @M3noincremental! > XXX > > (And @M3paranoidgc doesn't seem to be any more paranoid than the > usual one.) > > Maybe this is a stupid question... why are Pause and AlertPause > implemented with different system calls? (Note that I had another > program that was exhibiting the same type of processor greed, and > changing all occurrences of Pause to AlertPause in that program > didn't seem to cure it.) > > I think mentor and Juno show the 100% CPU symptoms as well. Yes, > I just re-ran mentor and I got the same assertion failing. > > ---- > > One last issue: there is indeed one more problem. @M3nogc does > solve the cpu utilization and Utime problems. It does not, however, > solve the protection bug (#1 above). Something's up, because Network > Objects do work fine, but reading and writing certain things to > disk does not appear to work (and those pickles were written by the > same executable as the one that tried to read them). All these > programs work reliably under PM3 on both FreeBSD and Windows > 2000/cygwin (not that I am suggesting that they are bug free). > > Mika > > > Tony Hosking writes: >> >> On Jul 15, 2007, at 9:53 PM, Mika Nystrom wrote: >> >>> Hello there, >>> >>> I am now back to trying to get my system compiled under CM3. Not >>> to pick on CM3 or anything, but my old PM3s still have no trouble >>> with it! >> >> PS Old PM3s don't have the new compiler-driven incremental >> collection scheme, so you will hopefully gain fromm moving to CM3 so >> long as we can fix your problem. I should be able to diagnose this >> without too much trouble. Any chance you can run with the >> @M3paranoidgc flag passed to tok? >> >>> >>> I'm back to staring at the following: >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 2310 >>> *** >>> >>> Here's how I got it: I ran the "tok" program from my example on one >>> of the example files (not sure if this is part of the distributed >>> "caltech-parser" or not). The revision of RTCollector.m3 is 1.29. >>> >>> I spoke to the author of "tok" last week (who now programs in a >>> kind of bastardized C++ with Modula-3 keywords and a garbage >>> collector), and he said this program actually does very little work. >>> It's just an interface generator that makes interfaces to declare >>> a few constants. Why it seems to have so much trouble running is >>> a mystery to me. >>> >>> traceback: >>> >>> (gdb) where >>> #0 0x9004308c in kill () >>> #1 0x9009fb3c in abort () >>> #2 0x00096f48 in RTOS__Crash () at RTOS.m3:20 >>> #3 0x0005bcd8 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at >>> RTProcess.m3:65 >>> #4 0x0008e4d8 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at >>> RTError.m3:115 >>> #5 0x0008e084 in RTError__MsgS (M3_AJWxb1_file=0xc6420, >>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0xca418, >>> M3_Bd56fi_msgB=0xcbed8, M3_Bd56fi_msgC=0xca418) at RTError.m3:40 >>> #6 0x0008eb80 in RTException__Crash (M3_Cblw37_a=0xbfffee20, >>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0xcb580) at RTException.m3:79 >>> #7 0x0008e744 in RTException__DefaultBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:39 >>> #8 0x0008e60c in RTException__InvokeBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:25 >>> #9 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at >>> RTExFrame.m3:29 >>> #10 0x0008e838 in RTException__DefaultBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:47 >>> #11 0x0008e60c in RTException__InvokeBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:25 >>> #12 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at >>> RTExFrame.m3:29 >>> #13 0x00079738 in RTHooks__ReportFault (M3_AJWxb1_module=0xb3ec0, >>> M3_AcxOUs_info=73920) at RTHooks.m3:110 >>> #14 0x0006ff44 in _m3_fault (M3_AcxOUs_arg=73920) >>> #15 0x0006bcec in RTHooks__CheckStoreTraced >>> (M3_Af40ku_ref=0xb24368) at RTCollector.m3:2310 >>> #16 0x000700dc in ThreadPThread__InnerLockMutex >>> (M3_AYIbX3_m=0xb24368, M3_BXP32l_self=0xb244b0) at >>> ThreadPThread.m3:126 >>> #17 0x000704d0 in ThreadPThread__LockMutex (M3_AYIbX3_m=0xb24368) >>> at ThreadPThread.m3:153 >>> #18 0x00019abc in Wr__PutText (M3_BxxOH1_wr=0xb24368, >>> M3_Bd56fi_t=0xb403d4) at Wr.m3:93 >>> #19 0x00003e94 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113 >>> #20 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at >>> RTLinker.m3:399 >>> #21 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at >>> RTLinker.m3:113 >>> #22 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at >>> RTLinker.m3:122 >>> #23 0x00001ecc in main (argc=4, argv=0xbffffb30, envp=0xbffffb44) >>> at _m3main.mc:4 >>> (gdb) >>> >>> Line 113 in Main.m3 is: >>> >>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); >>> >>> (Bundle is made by m3bundle) >>> >>> OS: >>> Darwin lapdog.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> This is a CM3 checkout from yesterday, built cleanly according to >>> your instructions (starting with an absolutely clean system and >>> bootstrapped using binary version 5.4.0). I managed to screw it >>> up at one point but I ran do-cm3-std realclean and do-cm3-core >>> realclean several times. >>> >>> But isn't this the bug you already fixed? I just don't see how I >>> could possibly be getting an old RTCollector.m3 file in my system. >>> I cleaned it obsessively while I was building it. >>> >>> I am using the cfg file you sent me, too. (I copied it in, in place >>> of the 5.4.0 default cfg.) You can see I am using pthreads. >>> >>> @M3noincremental and @M3nogc work, as usual. >>> >>> ---------- >>> >>> I saw another problem. I was running mentor, the packet routing >>> animation, and hit an assertion in ThreadPThread.m3. >>> >>> >>> [lapdog:~] mika% mentor >>> >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 673 >>> *** >>> >>> Abort >>> >>> WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*> >>> END; >>> WITH r = Upthread.attr_init(attr) DO <*ASSERT r=0*> END; >>> WITH r = Upthread.attr_getstacksize(attr, bytes) DO >>> <*ASSERT r=0*> END; >>> bytes := MAX(bytes, size * ADRSIZE(Word.T)); >>> WITH r = Upthread.attr_setstacksize(attr, bytes) DO >>> <*ASSERT r=0*> END; (* line 673 *) >>> WITH r = Upthread.create(act.handle, attr, ThreadBase, >>> act) DO >>> <*ASSERT r=0*> >>> END; >>> act.next := allThreads; >>> act.prev := allThreads.prev; >>> act.size := size; >>> allThreads.prev.next := act; >>> allThreads.prev := act; >>> WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*> >>> END; >>> END; >>> >>> Is it trying to make too many threads? Is there a practical limit >>> on the number of threads under pthreads? (The code I am eventually >>> going to want to build will want to make hundreds and possibly >>> thousands of concurrently executing threads, which I don't think >>> is a problem with ThreadPosix, and I'll be pretty disappointed if >>> that turns out to be a problem with pthreads...well I suppose I can >>> always go back to user-level threads.) >>> >>> Mika >>> >>> >>> Tony Hosking writes: >>>> Sigh, this is a knock-on bug that manifests as a result of the >>>> supposed "fix" I made in response to your previous post. As it >>>> turns >>>> out, the user-level threads code has some badness built in with >>>> respect to incremental GC. I need to rework the user-level >>>> threading >>>> code to totally eliminate use of traced references in the code for >>>> ProcessStacks. The ring of threads needs to be maintained in an >>>> untraced data structure for the newer GC code to work properly. >>>> This >>>> is something that is very carefully done in the pthreads-based >>>> system- >>>> level threading that is used on all the platforms I typically >>>> maintain locally (SOLgnu/SOLsun, LINUXLIBC6, I386_DARWIN, >>>> PPC_DARWIN), so I haven't seen this problem so extensively. You >>>> are >>>> correct that running without incremental collection (using >>>> @M3noincremental) will avoid the problem until I am able to come up >>>> with a fix. >>>> >>>> On Jul 2, 2007, at 6:35 AM, Mika Nystrom wrote: >>>> >>>>> Ok, things are certainly better on FreeBSD/i386 now. I just spent >>>>> a few minutes playing a newly compiled tetris. >>>>> >>>>> However, I still get that very first error I wrote about: >>>>> >>>>> /home/mika/u/parserlib/ktok/FreeBSD4/tok ../src/Lang.t -o >>>>> LangTok.i3 >>>>> WELCOME! >>>>> GOT TOKPARAMS! >>>>> GOT TOKENS >>>>> GOT SUBS! >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** <*ASSERT*> failed. >>>>> *** file "../src/runtime/common/RTCollector.m3", line 2310 >>>>> *** >>>>> >>>>> What I did was... I wasn't sure exactly what state my CM3 was in, >>>>> as usual, so I deleted all of /usr/local/cm3, plus my repository >>>>> checkout, checked it out from scratch, and followed your bootstrap >>>>> instructions of June 24 to the letter, except that where you said >>>>> to do "do-cm3-std.sh realclean" I did "do-cm3-core.sh realclean" >>>>> and then "do-cm3-std.sh realclean", built the stage 1 and stage 2, >>>>> installed the new compiler. No problems until trying to run >>>>> this code, which is part of our local version of the "caltech- >>>>> parser"... >>>>> Here we go: >>>>> >>>>> >>>>> Program received signal SIGABRT, Aborted. >>>>> 0x68b5e0c7 in kill () from /lib/libc.so.5 >>>>> (gdb) where >>>>> #0 0x68b5e0c7 in kill () from /lib/libc.so.5 >>>>> #1 0x68b5312e in raise () from /lib/libc.so.5 >>>>> #2 0x68bc6cef in abort () from /lib/libc.so.5 >>>>> #3 0x682bc7f2 in RTOS__Crash () at RTOS.m3:20 >>>>> #4 0x682b3b66 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at >>>>> RTProcess.m3:65 >>>>> #5 0x682b1e30 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at >>>>> RTError.m3:115 >>>>> #6 0x682b1b71 in RTError__MsgS (M3_AJWxb1_file=0x682dd4c8, >>>>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0x682df048, >>>>> M3_Bd56fi_msgB=0x682d9630, M3_Bd56fi_msgC=0x682df048) at >>>>> RTError.m3:40 >>>>> #7 0x682b21f4 in RTException__Crash (M3_Cblw37_a=0xbfbfe0b8, >>>>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x682d94e0) at >>>>> RTException.m3:79 >>>>> #8 0x682b1f58 in RTException__DefaultBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:39 >>>>> #9 0x682b1ebc in RTException__InvokeBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:25 >>>>> #10 0x682bdc37 in RTException__Raise (M3_Cblw37_act=0xbfbfe0b8) at >>>>> RTExFrame.m3:29 >>>>> #11 0x682b1ff8 in RTException__DefaultBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:47 >>>>> #12 0x682b1ebc in RTException__InvokeBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:25 >>>>> #13 0x682bdc37 in RTException__Raise (M3_Cblw37_act=0xbfbfe0b8) at >>>>> RTExFrame.m3:29 >>>>> #14 0x6829da9e in RTHooks__ReportFault >>>>> (M3_AJWxb1_module=0x682dd640, M3_AcxOUs_info=73920) at >>>>> RTHooks.m3:110 >>>>> #15 0x682afc48 in _m3_fault (M3_AcxOUs_arg=73920) from /usr/local/ >>>>> cm3/pkg/m3core/FreeBSD4/libm3core.so.5 >>>>> #16 0x682ad065 in RTHooks__CheckStoreTraced >>>>> (M3_Af40ku_ref=0x68c2b104) at RTCollector.m3:2310 >>>>> #17 0x682bfba2 in ThreadPosix__LockMutex (M3_AYIbX3_m=0x68c2b104) >>>>> at ThreadPosix.m3:416 >>>>> #18 0x681ab817 in Wr__PutText (M3_BxxOH1_wr=0x68c2b104, >>>>> M3_Bd56fi_t=0x68c05608) at Wr.m3:93 >>>>> #19 0x0804a445 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113 >>>>> #20 0x682b120a in RTLinker__RunMainBody (M3_DjPxE3_m=0x804cae0) at >>>>> RTLinker.m3:399 >>>>> #21 0x682b0735 in RTLinker__AddUnitI (M3_DjPxE3_m=0x804cae0) at >>>>> RTLinker.m3:113 >>>>> #22 0x682b07bc in RTLinker__AddUnit (M3_DjPxE5_b=0x8049e50) at >>>>> RTLinker.m3:122 >>>>> #23 0x080491f5 in main (argc=4, argv=0xbfbfe40c, envp=0xbfbfe420) >>>>> at _m3main.mc:4 >>>>> (gdb) >>>>> >>>>> 2302 PROCEDURE CheckStoreTraced (ref: REFANY) = >>>>> 2303 VAR p := Word.RightShift (LOOPHOLE(ref, Word.T), >>>>> LogBytesPerPage); >>>>> 2304 BEGIN >>>>> 2305 RTOS.LockHeap (); >>>>> 2306 INC(checkStoreTraced); >>>>> 2307 >>>>> 2308 WITH h = HeaderOf (LOOPHOLE(ref, RefReferent)) DO >>>>> 2309 <*ASSERT h.typecode # RT0.TextLitTypecode*> >>>>> 2310 <*ASSERT NOT h.gray*> >>>>> 2311 >>>>> 2312 IF h.dirty THEN >>>>> 2313 <*ASSERT NOT desc[p - p0].clean*> >>>>> 2314 ELSE >>>>> 2315 h.dirty := TRUE; >>>>> 2316 IF desc[p - p0].clean THEN >>>>> 2317 desc[p - p0].clean := FALSE; >>>>> 2318 IF perfOn THEN PerfChange(p, PageCount(p)); END; >>>>> 2319 END; >>>>> 2320 END; >>>>> 2321 END; >>>>> 2322 >>>>> 2323 RTOS.UnlockHeap(); >>>>> 2324 RETURN; >>>>> 2325 END CheckStoreTraced; >>>>> >>>>> I believe this is the same as the first bug I ran across. The >>>>> program >>>>> (ktok) does appear to work fine with @M3nogc. >>>>> >>>>> Further information: I am also "able" to get mentor and Juno to >>>>> crash on this line 2310. I checked the bootstrapping process by >>>>> building a third-stage bootstrapped compiler, and it was byte-for- >>>>> byte >>>>> identical to the second-stage bootstrap. Finally, I am still a >>>>> bit >>>>> worried about libraries (maybe across the different booting >>>>> stages) >>>>> getting polluted: I am able to run Juno, mentor, etc., except for >>>>> the garbage-collection problem, but my own Trestle applications >>>>> crash somewhere in the (C) X libraries, even though they have >>>>> worked >>>>> fine on several other versions of Modula-3. (Most likely, of >>>>> course, >>>>> it's some sort of bug of mine... generally I am not in the >>>>> habit of >>>>> blaming the libraries or compiler, but you never know!) >>>>> >>>>> The line-2310 crashes also seem to go away with @M3noincremental, >>>>> by the >>>>> way. >>>>> >>>>> >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>>> I've just checked in a fix to ThreadPosix.m3 that eliminates your >>>>>> problem with user-level threads. I have tested this on >>>>>> I386_DARWIN >>>>>> and it appears to be working just fine now. Please try again >>>>>> with >>>>>> the updated ThreadPosix.m3. >>>>>> >>>>>> On Jun 25, 2007, at 3:05 PM, Mika Nystrom wrote: >>>>>> >>>>>>> Indeed, -g was one of the culprits. I changed it to -gstabs+ >>>>>>> and >>>>>>> got a bit further... (please scroll down to STEP 2, sorry) >>>>>>> >>>>>>> Tony Hosking writes: >>>>>>>> Sounds like we really need some work done in this area. I very >>>>>>>> rarely use the build scripts, since I bootstrap manually >>>>>>>> from old >>>>>>>> compilers to new compilers rather than use the scripts. I >>>>>>>> suggest >>>>>>>> the following approach, which I hope you will try, and then >>>>>>>> report >>>>>>>> back on. >>>>>>>> >>>>>>>> Install the bootstrap compiler as you did originally: >>>>>>>> >>>>>>>>> rm -rf /usr/local/cm3/* >>>>>>>>> >>>>>>>>> cd ~/cm3-cvs >>>>>>>>> mkdir boot >>>>>>>>> cd boot >>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz >>>>>>>>> ./cminstall >>>>>>>> >>>>>>>> Now you will have some kind of cm3 installed, presumably in / >>>>>>>> usr/ >>>>>>>> local/cm3/bin/cm3. >>>>>>>> >>>>>>>> Make sure you have a fresh CVS checkout in directory cm3 (let's >>>>>>>> assume this is in your home directory ~/cm3). Also, make sure >>>>>>>> you >>>>>>>> have an up-to-date version of the CM3 backend compiler cm3cg >>>>>>>> installed by executing the following: >>>>>>>> >>>>>>>> STEP 0: >>>>>>>> >>>>>>>> export CM3=/usr/local/cm3/bin/cm3 >>>>>>>> cd ~/cm3/m3-sys/m3cc >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> >>>>>>>> You can skip this last step if you know your backend compiler >>>>>>>> is up >>>>>>>> to date. >>>>>>>> >>>>>>>> Now, let's build the new compiler from scratch (this is the >>>>>>>> sequence >>>>>>>> I use regularly to test changes to the run-time system >>>>>>>> whenever I >>>>>>>> make them): >>>>>>>> >>>>>>>> STEP 1: >>>>>>>> >>>>>>>> cd ~/cm3/m3-libs/m3core >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-libs/libm3 >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3middle >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3linker >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3front >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3quake >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/cm3 >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> >>>>>>>> At this point you should have a bootstrapped version of cm3 >>>>>>>> installed >>>>>>>> in the directory /usr/local/cm3/pkg/cm3/TARGET/cm3 (where >>>>>>>> TARGET is >>>>>>>> the CM3 target platform you are building on -- e.g., >>>>>>>> LINUXLIBC6, >>>>>>>> PPC_DARWIN, ...). Note that this did not overwrite your >>>>>>>> original >>>>>>>> installed compiler in /usr/local/cm3/bin/cm3. We >>>>>>>> are now going to test the new compiler, which was built using >>>>>>>> the old >>>>>>>> compiler, by bootstrapping it one more time. >>>>>>>> >>>>>>>> From here on out, please replace TARGET with your target >>>>>>>> platform as >>>>>>>> appropriate. >>>>>>>> >>>>>>>> STEP 2: >>>>>>>> >>>>>>>> export CM3=/usr/local/cm3/pkg/cm3/TARGET/cm3 >>>>>>>> cd ~/cm3/scripts >>>>>>>> ./do-cm3-std.sh realclean >>>>>>>> REPEAT STEP 1 to rebuild the libraries and the compiler >>>>>>>> using the >>>>>>>> STEP 1 bootstrap compiler. >>>>>>>> >>>>>>>> Now you have a STEP 2 bootstrap compiler installed in /usr/ >>>>>>>> local/ >>>>>>>> cm3/ >>>>>>>> pkg/cm3/TARGET/cm3. Let's assume the new compiler now works >>>>>>>> properly >>>>>>>> since it successfully bootstrapped itself, but to be sure we >>>>>>>> can >>>>>>>> now >>>>>>>> use it to rebuild the world: >>>>>>> >>>>>>> Ok, I got this far. I built the step 1 (m3core...cm3), set my >>>>>>> compiler to the newly-built compiler, and rebuilt >>>>>>> (m3core...cm3). >>>>>>> No errors anywhere, beautiful. >>>>>>> >>>>>>>> >>>>>>>> cd ~/cm3/scripts >>>>>>>> ./do-cm3-std.sh realclean >>>>>>>> ./do-cm3-std.sh buildship >>>>>>> >>>>>>> Here's where it dies: >>>>>>> >>>>>>> ./do-cm3-std.sh buildship >>>>>>> CM3C = >>>>>>> /big/home2/mika/2/cm3-cvs/fresh/cm3/scripts/pkgmap.sh -c "/usr/ >>>>>>> local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/home2/ >>>>>>> mika/2/ >>>>>>> cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 - >>>>>>> ship - >>>>>>> DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' " m3core libm3 >>>>>>> patternmatching m3middle m3quake m3scanner m3tools m3cgcat >>>>>>> m3cggen >>>>>>> m3gdb m3bundle arithmetic bitvector digraph parseparams >>>>>>> realgeometry set slisp sortedtableextras table-list tempfiles >>>>>>> tcp >>>>>>> udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO >>>>>>> commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser >>>>>>> cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr >>>>>>> sharedobj sharedobjgen odbc postgres95 db smalldb stable >>>>>>> stablegen >>>>>>> X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps >>>>>>> formsvbt formsview formsedit codeview mg mgkit opengl anim3D >>>>>>> zeus >>>>>>> m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq >>>>>>> obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd >>>>>>> obliqsrvui obliqbinmin obliqbinstd obliqbin! >>>>>>> ui obliqbinanim visualobliq vocgi voquery vorun webvbt >>>>>>> recordheap >>>>>>> rehearsecode replayheap showheap shownew showthread pkl-fonts >>>>>>> juno- >>>>>>> machine juno-compiler juno-app cube calculator fisheye mentor >>>>>>> === package /big/home2/mika/2/cm3-cvs/fresh/cm3/m3-libs/ >>>>>>> m3core === >>>>>>> +++ /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/ >>>>>>> home2/ >>>>>>> mika/2/cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/ >>>>>>> cm3 - >>>>>>> ship -DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' +++ >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>> >>>>>>> Abort trap >>>>>>> *** execution of failed *** >>>>>>> >>>>>>> This time it appears to be cm3 itself that's crashing: >>>>>>> >>>>>>> (310)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>$CM3 -keep - >>>>>>> commands >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> Abort >>>>>>> >>>>>>> What follows is what m3gdb has to say about this. I take it >>>>>>> that >>>>>>> the last error message comes from my -gstabs+ option. m3gdb >>>>>>> doesn't >>>>>>> like this new binary: it can't print variables and sometimes >>>>>>> crashes >>>>>>> trying. Would I have better luck with "-gstabs", do you >>>>>>> think? Or >>>>>>> do I just need to fix the compile process and install a new >>>>>>> m3gdb? >>>>>>> (I take it there is a newer one: mine is very old. But I >>>>>>> remember >>>>>>> that m3gdb doesn't always work that well...) >>>>>>> >>>>>>> Mika >>>>>>> >>>>>>> #1 16_81a619d in __raise () >>>>>>> #2 16_81a3b8f in abort () >>>>>>> #3 16_8178d16 in RTOS.Crash () at RTOS.m3:20 >>>>>>> #4 16_8171fd2 in RTProcess.Crash (msg=NIL) at RTProcess.m3:65 >>>>>>> #5 16_8170428 in RTError.EndError (crash=TRUE) at >>>>>>> RTError.m3:115 >>>>>>> #6 16_8170169 in RTError.MsgS (file=16_820a508, line=690, >>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at >>>>>>> RTError.m3:40 >>>>>>> #7 16_81707ec in RTException.Crash (a=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79 >>>>>>> #8 16_8170550 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39 >>>>>>> #9 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #10 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #11 16_81705f0 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47 >>>>>>> #12 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #13 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #14 16_8160bba in RTHooks.ReportFault (module=16_820a680, >>>>>>> info=22080) at RTHooks.m3:110 >>>>>>> #15 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0 >>>>>>> #16 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> #17 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3300) at >>>>>>> RTCollector.m3:2296 >>>>>>> #18 16_814400c in Stdio.ShutDown () at Stdio.m3:43 >>>>>>> #19 16_8171f51 in RTProcess.InvokeExitors () at RTProcess.m3:40 >>>>>>> #20 16_8171fc5 in RTProcess.Crash (msg=NIL) at RTProcess.m3:61 >>>>>>> #21 16_8170428 in RTError.EndError (crash=TRUE) at >>>>>>> RTError.m3:115 >>>>>>> #22 16_8170169 in RTError.MsgS (file=16_820a508, line=690, >>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at >>>>>>> RTError.m3:40 >>>>>>> #23 16_81707ec in RTException.Crash (a=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79 >>>>>>> #24 16_8170550 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39 >>>>>>> #25 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #26 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #27 16_81705f0 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47 >>>>>>> #28 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #29 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #30 16_8160bba in RTHooks.ReportFault (module=16_820a680, >>>>>>> info=22080) at RTHooks.m3:110 >>>>>>> #31 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0 >>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3004) at >>>>>>> RTCollector.m3:2296 >>>>>>> #34 16_817c41e in ThreadF.ProcessStacks (p=16_816415e) at >>>>>>> ThreadPosix.m3:522 >>>>>>> #35 16_8165213 in RTCollector.CollectSomeInStateZero () at >>>>>>> RTCollector.m3:845 >>>>>>> #36 16_8164d2c in RTCollector.CollectSome () at >>>>>>> RTCollector.m3:741 >>>>>>> #37 16_816487b in RTCollector.CollectEnough () at >>>>>>> RTCollector.m3:659 >>>>>>> #38 16_81673cd in RTHeapRep.AllocTraced (def=16_81f8f38, >>>>>>> dataSize=8200, dataAlignment=4, initProc=16_bfbfe0f4, >>>>>>> pool=RECORD >>>>>>> desc = RECORD space = Current; generation = Younger; pure = >>>>>>> FALSE; >>>>>>> note = Allocated; gray = FALSE; clean = FALSE; continued = >>>>>>> FALSE; link = 0; END; notAfter = {Copied}; page = 0; stack = 0; >>>>>>> next = NIL; limit = NIL; busy = FALSE; END) >>>>>>> at RTCollector.m3:1417 >>>>>>> #39 16_816218e in RTAllocator.GetOpenArray (def=16_81f8f38, s= >>>>>>> [2048]) at RTAllocator.m3:308 >>>>>>> #40 16_8161737 in RTHooks.AllocateOpenArray (defn=16_81f8f38, s= >>>>>>> [2048]) at RTAllocator.m3:156 >>>>>>> #41 16_8129d56 in M3ID_M3 (mode=1) at M3ID.m3:40 >>>>>>> #42 16_816f802 in RTLinker.RunMainBody (m=16_81f8cc0) at >>>>>>> RTLinker.m3:399 >>>>>>> #43 16_816f6ca in RTLinker.RunMainBody (m=16_81c0880) at >>>>>>> RTLinker.m3:379 >>>>>>> #44 16_816f6ca in RTLinker.RunMainBody (m=16_81c06a0) at >>>>>>> RTLinker.m3:379 >>>>>>> #45 16_816f6ca in RTLinker.RunMainBody (m=16_81bc920) at >>>>>>> RTLinker.m3:379 >>>>>>> #46 16_816ed2d in RTLinker.AddUnitI (m=16_81bc920) at >>>>>>> RTLinker.m3:113 >>>>>>> #47 16_816edb4 in RTLinker.AddUnit (b=16_8065527) at >>>>>>> RTLinker.m3:122 >>>>>>> module "_m3main": missing debug info for global data >>>>>>> >>>>>>> (gdb) up 32 >>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> RTCollector.m3:690: No such file or directory. >>>>>>> (gdb) >>>>>>> Suspended >>>>>>> (360)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>find ../.. -name >>>>>>> RTCollector.m3 >>>>>>> ../../m3-libs/m3core/src/runtime/common/RTCollector.m3 >>>>>>> (361)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>fg >>>>>>> m3gdb /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 >>>>>>> (gdb) dir ../../m3-libs/m3core/src/runtime/common/ >>>>>>> Source directories searched: /big/home2/mika/2/cm3-cvs/fresh/ >>>>>>> cm3/m3- >>>>>>> libs/m3core/../../m3-libs/m3core/src/runtime/common:$cdir:$cwd >>>>>>> (gdb) list >>>>>>> 685 VAR timeOnEntry, timeOnExit: Time.T; (* time of >>>>>>> collector entry/exit *) >>>>>>> 686 >>>>>>> 687 PROCEDURE CollectorOn () = >>>>>>> 688 (* LL >= RTOS.LockHeap *) >>>>>>> 689 BEGIN >>>>>>> 690 <* ASSERT NOT collectorOn *> >>>>>>> 691 collectorOn := TRUE; >>>>>>> 692 >>>>>>> 693 IF incremental AND NOT RTLinker.incremental >>>>>>> 694 OR generational AND NOT RTLinker.generational THEN >>>>>>> (gdb) print collectorOn >>>>>>> can't find identifier: collectorOn >>>>>>> (gdb) up >>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3004) at >>>>>>> RTCollector.m3:2296 >>>>>>> 2296 CollectorOn(); >>>>>>> (gdb) print collectorOn >>>>>>> can't find identifier: collectorOn >>>>>>> (gdb) print ref >>>>>>> Segmentation fault >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Assuming this succeeded then we can be pretty sure /usr/local/ >>>>>>>> cm3/ >>>>>>>> pkg/ >>>>>>>> cm3/TARGET/cm3 is good, so we can make it our default >>>>>>>> compiler by >>>>>>>> replacing the original /usr/local/cm3/bin/cm3: >>>>>>>> >>>>>>>> cp $CM3 /usr/local/cm3/bin/cm3 >>>>>>>> >>>>>>>> On Jun 23, 2007, at 2:38 PM, Mika Nystrom wrote: >>>>>>>> >>>>>>>>> Ok, I'm sorry if I seem a bit dimwitted in the morning like >>>>>>>>> this, >>>>>>>>> but how exactly does one get started? I wish there were a >>>>>>>>> file >>>>>>>>> called >>>>>>>>> "GETTING_STARTED" or something like that in scripts... >>>>>>>>> >>>>>>>>> My Mac is very slow so I switched to my FreeBSD/i386 system >>>>>>>>> (which has >>>>>>>>> PM3 happily installed on it) and tried to install CM3 from >>>>>>>>> scratch. >>>>>>>>> Here are the exact commands I typed. >>>>>>>>> >>>>>>>>> >>>>>>>>> rm -rf /usr/local/cm3/* >>>>>>>>> >>>>>>>>> cd ~/cm3-cvs >>>>>>>>> mkdir boot >>>>>>>>> cd boot >>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz >>>>>>>>> ./cminstall >>>>>>>>> >>>>>>>>> # now I seem to have some kind of cm3 installed, /usr/local/ >>>>>>>>> cm3/ >>>>>>>>> bin/ >>>>>>>>> cm3 >>>>>>>>> >>>>>>>>> cd cm3 # location of my CM3 checkout >>>>>>>>> cvs update -d . >>>>>>>>> >>>>>>>>> cd scripts >>>>>>>>> ./boot-cm3-with-m3.sh realclean >>>>>>>>> ./do-cm3-std.sh realclean >>>>>>>>> >>>>>>>>> ./upgrade.sh # fails here, libm3 not >>>>>>>>> compiled >>>>>>>>> ./boot-cm3-with-m3.sh build # builds cm3, but fails on >>>>>>>>> cminstall, patternmatching not built >>>>>>>>> >>>>>>>>> ./do-cm3-std.sh build # OK >>>>>>>>> ./do-cm3-std.sh buildship # OK >>>>>>>>> >>>>>>>>> ./boot-cm3-with-m3.sh realclean # start over >>>>>>>>> ./boot-cm3-with-m3.sh build # OK >>>>>>>>> ./boot-cm3-with-m3.sh buildship # OK >>>>>>>>> >>>>>>>>> ./do-cm3-std.sh realclean # OK >>>>>>>>> ./do-cm3-std.sh build # dies miserably... maybe >>>>>>>>> the >>>>>>>>> compiler can't handle the new libraries? >>>>>>>>> >>>>>>>>> ./install-cm3-compiler.sh upgrade # OK, new cm3 binary >>>>>>>>> installed >>>>>>>>> >>>>>>>>> After all that, "game over." I have a cm3 that segfaults. >>>>>>>>> >>>>>>>>> Text.i3: In function 'Text_I3': >>>>>>>>> Text.i3:81: internal compiler error: Segmentation fault >>>>>>>>> Please submit a full bug report, >>>>>>>>> with preprocessed source if appropriate. >>>>>>>>> See 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? From hosking at cs.purdue.edu Mon Jul 16 18:32:25 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:32:25 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: Again, please confirm that you are using the CVS head. 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 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? From hosking at cs.purdue.edu Mon Jul 16 18:47:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:47:06 -0400 Subject: [M3devel] User-level threading In-Reply-To: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> References: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Message-ID: <4E226F4D-9281-4FBA-9306-591A39ED64CC@cs.purdue.edu> This runs fine for me on Darwin pthreads up until it fails trying to create a new pthread after 6982 threads: the call to pthread_create returns an error code. I am assuming the error is due to hitting some system limit. On Jul 16, 2007, at 12:50 AM, Mika Nystrom wrote: > MODULE Main; > IMPORT Thread; > IMPORT Rd, Stdio, Wr, Random, Fmt; > > TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; > > > PROCEDURE A(cl : Cl) : REFANY = > VAR rand := NEW(Random.Default).init(); > BEGIN > LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText > (Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END > END A; > > CONST Nthreads=10000; > BEGIN > FOR i := 1 TO Nthreads DO > Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush > (Stdio.stdout); > EVAL Thread.Fork(NEW(Cl)) > END; > > LOOP > WITH c = Rd.GetChar(Stdio.stdin) DO > IF c = 'q' THEN EXIT END > END > END > END Main. From hosking at cs.purdue.edu Mon Jul 16 18:57:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:57:28 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: 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 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? From mika at async.caltech.edu Mon Jul 16 21:33:53 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 16 Jul 2007 12:33:53 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Mon, 16 Jul 2007 12:57:28 EDT." Message-ID: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Tue Jul 17 00:53:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 18:53:49 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> References: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> Message-ID: <31544177-4CC1-42C6-8306-DF3AD5BC5775@cs.purdue.edu> 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 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? From mika at async.caltech.edu Tue Jul 17 09:31:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 17 Jul 2007 00:31:44 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Mon, 16 Jul 2007 18:53:49 EDT." <31544177-4CC1-42C6-8306-DF3AD5BC5775@cs.purdue.edu> Message-ID: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> 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=, M3_CVvbAZ_session=0x1f93290, M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=) 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=, M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Tue Jul 17 16:34:53 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Jul 2007 10:34:53 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> References: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> Message-ID: Good. I'll try to digest your report more deeply before getting back. Generally, try running with @M3noincremental @M3nogenerational to run with simple GC but without the bells and whistles. You can add @M3paranoidgc to be particularly careful. That way, at least we know that you are getting the benefit of GC without major complications. 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=, M3_CVvbAZ_session=0x1f93290, > M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', > M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid= 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=, > M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Thu Jul 19 05:53:38 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 18 Jul 2007 23:53:38 -0400 Subject: [M3devel] LONGINT Message-ID: I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. From wagner at elegosoft.com Thu Jul 19 08:23:50 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Jul 2007 08:23:50 +0200 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <20070719062350.GA12517@elegosoft.com> On Wed, Jul 18, 2007 at 11:53:38PM -0400, Tony Hosking wrote: > I've successfully bootstrapped a CM3 compiler that supports LONGINT > as a 64-bit integer type (equivalent to "long long" in C) in addition > to INTEGER (same as "long" in C). This will be useful for > simplifying interfaces to C library routines that expect to be able > to treat 64-bit integers such as "off_t" for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type > (I'm not sure this would ever be a good idea) so it cannot be used to > index arrays, define enumerations etc., though the simple operations > ABS, MAX, MIN, addition, comparisons, MOD, multiplication, > subtraction, assignment, are all supported. This includes changes to > m3core (with support for Long.T similar to Word.T, plus RTTipe and > RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, > m3front, and the gcc-based compiler backend. There is still work > that needs to be done to support and test all the other M3 tools such > as network objects, etc., with support and testing needed in m3tk for > the new type, as well as in other tools like m3browser. This sounds great! As this topic had been discussed several times, and nothing ever came of it, I'd rather thought that it wouldn't be different this time. So at last we have explicit 64 bit support. I assume that this works on 32 bit platforms as well as an 64 bit platforms? 32 bit backends were the main problem when I tried to build code generation support some years ago, as suddenly everything needed to be 64 bit long in the CG interfaces. > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head just so that it gets some > testing, but perhaps that is premature. I can confirm a complete > bootstrap via "do-cm3-std.sh" that appears to produce perfectly > functional executables, including mentor, etc. Well, as there are no other major projects ongoing in development as far as I know there principally is no need for special care. If you can produce a working core system on two or three target platforms and provide upgrading instructions, we can put it in the main trunk. I'd strongly suggest to tag _everything_ before and after commit of the new code though, for example with cvs tag devel_LONGINT_start cvs commit cvs tag devel_LONGINT_RC01 just to make sure that we can easily revert to prior versions. We'll have to update the M3 language specs, too, and put up some HTML documentation on the servers. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Thu Jul 19 15:13:05 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 08:13:05 -0500 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F6361.9010407@wichita.edu> I'll volunteer to do the update to the language definition, as that is an interest of mine. Tony Hosking wrote: > I've successfully bootstrapped a CM3 compiler that supports LONGINT as > a 64-bit integer type (equivalent to "long long" in C) in addition to > INTEGER (same as "long" in C). This will be useful for simplifying > interfaces to C library routines that expect to be able to treat 64-bit > integers such as "off_t" for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type (I'm > not sure this would ever be a good idea) so it cannot be used to index > arrays, define enumerations etc., though the simple operations ABS, > MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, > assignment, are all supported. This includes changes to m3core (with > support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) > and libm3 for Pickle2, as well as to m3middle, m3front, and the > gcc-based compiler backend. There is still work that needs to be done > to support and test all the other M3 tools such as network objects, > etc., with support and testing needed in m3tk for the new type, as well > as in other tools like m3browser. > > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head just so that it gets some testing, > but perhaps that is premature. I can confirm a complete bootstrap via > "do-cm3-std.sh" that appears to produce perfectly functional > executables, including mentor, etc. > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 16:33:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 10:33:37 -0400 Subject: [M3devel] LONGINT In-Reply-To: <20070719062350.GA12517@elegosoft.com> References: <20070719062350.GA12517@elegosoft.com> Message-ID: On Jul 19, 2007, at 2:23 AM, Olaf Wagner wrote: > On Wed, Jul 18, 2007 at 11:53:38PM -0400, Tony Hosking wrote: >> I've successfully bootstrapped a CM3 compiler that supports LONGINT >> as a 64-bit integer type (equivalent to "long long" in C) in addition >> to INTEGER (same as "long" in C). This will be useful for >> simplifying interfaces to C library routines that expect to be able >> to treat 64-bit integers such as "off_t" for lseek, etc. >> >> Currently, the compiler does not treat LONGINT as an ordinal type >> (I'm not sure this would ever be a good idea) so it cannot be used to >> index arrays, define enumerations etc., though the simple operations >> ABS, MAX, MIN, addition, comparisons, MOD, multiplication, >> subtraction, assignment, are all supported. This includes changes to >> m3core (with support for Long.T similar to Word.T, plus RTTipe and >> RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, >> m3front, and the gcc-based compiler backend. There is still work >> that needs to be done to support and test all the other M3 tools such >> as network objects, etc., with support and testing needed in m3tk for >> the new type, as well as in other tools like m3browser. > > This sounds great! As this topic had been discussed several times, > and nothing ever came of it, I'd rather thought that it wouldn't > be different this time. So at last we have explicit 64 bit support. > I assume that this works on 32 bit platforms as well as an 64 bit > platforms? 32 bit backends were the main problem when I tried to > build code generation support some years ago, as suddenly everything > needed to be 64 bit long in the CG interfaces. What I did was to allow both INTEGER precision and LONGINT precision in M3CG/CG much along the lines of the various floating point precisions (REAL, LONGREAL, EXTENDED). It did require pushing support for these alternatives all the way through to the back-end though the changes are more cosmetic than major refactoring. CM3 is a pretty clean compiler in that respect. > >> How best should I proceed to get this out to the community. I am >> tempted to push it into the CVS head just so that it gets some >> testing, but perhaps that is premature. I can confirm a complete >> bootstrap via "do-cm3-std.sh" that appears to produce perfectly >> functional executables, including mentor, etc. > > Well, as there are no other major projects ongoing in development > as far as I know there principally is no need for special care. > If you can produce a working core system on two or three target > platforms and provide upgrading instructions, we can put it in the > main trunk. I'd strongly suggest to tag _everything_ before and > after commit of the new code though, for example with > > cvs tag devel_LONGINT_start > cvs commit > cvs tag devel_LONGINT_RC01 > > just to make sure that we can easily revert to prior versions. OK, I'll do this. > > We'll have to update the M3 language specs, too, and put up > some HTML documentation on the servers. Yes, indeed. I would be keen to get a clean integration of LONGINT in the specs that makes sense. My biggest question for now is whether we should consider LONGINT as an ordinal type or not. Perhaps there need to be two different classes of ordinal type with different base types (INTEGER and LONGINT). > > Thanks for all the work, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 > Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 > 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | > Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From hosking at cs.purdue.edu Thu Jul 19 16:34:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 10:34:22 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469F6361.9010407@wichita.edu> References: <469F6361.9010407@wichita.edu> Message-ID: <6D9BD083-9E4A-4C64-A1FB-5F840D28971E@cs.purdue.edu> On Jul 19, 2007, at 9:13 AM, Rodney M. Bates wrote: > I'll volunteer to do the update to the language definition, as that > is an > interest of mine. Great! Let's try to flesh this out soon so I can try to get the compiler up to speed with what we spec out. > > Tony Hosking wrote: >> I've successfully bootstrapped a CM3 compiler that supports >> LONGINT as a 64-bit integer type (equivalent to "long long" in C) >> in addition to INTEGER (same as "long" in C). This will be >> useful for simplifying interfaces to C library routines that >> expect to be able to treat 64-bit integers such as "off_t" for >> lseek, etc. >> Currently, the compiler does not treat LONGINT as an ordinal type >> (I'm not sure this would ever be a good idea) so it cannot be used >> to index arrays, define enumerations etc., though the simple >> operations ABS, MAX, MIN, addition, comparisons, MOD, >> multiplication, subtraction, assignment, are all supported. This >> includes changes to m3core (with support for Long.T similar to >> Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, >> as well as to m3middle, m3front, and the gcc-based compiler >> backend. There is still work that needs to be done to support >> and test all the other M3 tools such as network objects, etc., >> with support and testing needed in m3tk for the new type, as well >> as in other tools like m3browser. >> How best should I proceed to get this out to the community. I am >> tempted to push it into the CVS head just so that it gets some >> testing, but perhaps that is premature. I can confirm a complete >> bootstrap via "do-cm3-std.sh" that appears to produce perfectly >> functional executables, including mentor, etc. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 17:27:48 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 11:27:48 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> References: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> Message-ID: 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=, M3_CVvbAZ_session=0x1f93290, > M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', > M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid= 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=, > M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Thu Jul 19 17:31:23 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 11:31:23 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: My LONGINT implementation addresses many of your concerns. The LONGINT space is segregated from the INT space. I want to come up with an implementation that also permits ordinals based on LONGINT in addition to the current system of ordinals based on INTEGER. This requires revisiting the language spec and pushing through the implications. I'm going to look at that briefly before moving on to fixing user-level threading for all targets. On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: > Hello everyone, > > I have read the various proposals for supporting integers of different > bit sizes and am getting a little worried that they are running > away from the traditional Modula-3 simplicity. As far as I know, > there is very little in Modula-3 that depends on the actual size > in bits of INTEGERs and CARDINALs. It doesn't seem to me to make > much sense to introduce types like Int32.T and Int64.T and then > make the definition Int32.T = INTEGER (on one platform) and Int64.T > = INTEGER (on another platform). I'm wondering if it would instead > be possible to introduce a new group of types in the sense that > Modula-3 now has integer types and floating-point types, and call > these types "fixed width" or "specified width" types. Conversions > between these types and INTEGER or CARDINAL would have to be done > using functions (operators) that are the analogs of FLOAT, ROUND, > etc. Standard arithmetic operators would be overloaded just like > they are today for integers and floating-point numbers. Am I just > duplicating someone else's proposal here? Perhaps this proposal > doesn't address everything one might want to do with these extended- > size types? > > Maybe I am just dreaming about getting Modula-3 running on a > DECsystem-20 with 36-bit integers...with pickles that are > interchangeable > with i386 pickles, of course. > > What do people want to do with these extended-size types anyhow? > It seems good to me that INTEGER is the largest type that I can > expect my processor to calculate efficiently with. I would use > BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible > and write my code to be flexible about the BYTE/BITSIZE... but OK, > I can see the rationale for hiding all this in the compiler (and > inlining everything) in the few cases where I might want four-function > arithmetic on (specifically) 64- or 128-bit integers. > > Mika > > Darko writes: >> Actually I stated the wrong reason for that one, it's really an >> argument against mixed integer assignment. >> >> And saying that it looks right from the C/C++ point of view is pretty >> damning... >> >> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >> >>> Mail from unsubscribed address forwarded to the list... >>> ---------------------------- Original Message >>> ---------------------------- >>> Subject: Re: A nonnative 64-bit language proposal >>> From: hendrik at topoi.pooq.com >>> Date: Wed, October 25, 2006 14:22 >>> To: m3devel at elegosoft.com >>> -------------------------------------------------------------------- >>> -- >>> ---- >>> >>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>> >>>> For your example to compute as an integer even if that overflows >>>> and >>>> it wouldn't as a longint seems right from my C/C++ point of view. >>> >>> I've always thought C/C++ were badly wrong on this one, even >>> from their own archaic low-level machine-oriented viewpoint. >>> Most computers have integer multiply instructions that return a >>> double-length product. >>> >>> -- hendrik >>> >>> From rodney.bates at wichita.edu Thu Jul 19 19:34:13 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 12:34:13 -0500 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: <469FA095.2000404@wichita.edu> Tony Hosking wrote: > My LONGINT implementation addresses many of your concerns. The LONGINT > space is segregated from the INT space. I want to come up with an > implementation that also permits ordinals based on LONGINT in addition > to the current system of ordinals based on INTEGER. This requires > revisiting the language spec and pushing through the implications. I'm > going to look at that briefly before moving on to fixing user-level > threading for all targets. > By "ordinals", do you mean enumerations? Subranges?. In the language definition, ordinals refers to both the above, plus INTEGER, with CHAR and BOOLEAN being enumerations. It is hard to image a use for enumerations with more than 2^32 values. As I recall, I was thinking this would add quite a bit of complexity to the language for negligible benefit. Subranges of LONGINT seem entirely useful and make for consistency. From a language definition standpoint, I think these just about fall into place with very little change. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 19 20:56:16 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 19 Jul 2007 14:56:16 -0400 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F7BAD.1E75.00D7.1@scires.com> Tony: I'd like to better understand the implications of your change as I do use LONGINT as an index in some applications. 1. On a computer with a 32-bit word size, will LONGINT be 32 bits or 64 bits? 2. I assume on a computer with a 64-bit word size, LONGINT will be 64 bits. Is there an option to get a 32-bit integer on these machines? 3. Would it make sense to keep LONGINT at 32-bits and make a new type, say LONGINT64, at 64-bits? Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> Tony Hosking 7/18/2007 11:53 PM >>> I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 19 21:23:54 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:23:54 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FA095.2000404@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> Message-ID: Here are my notes from a run through the language spec. Next step is to flesh out the additional bits in the compiler beyond what I announced yesterday. I would appreciate any feedback you can give as I look into this. 3. TYPES -Ordinal Types: There are three kinds of ordinal types: enumerations, subranges, and integers. There are two integer types, which in order of increasing range and precision are INTEGER and LONGINT. The base type of an ordinal value 'v' is its type (INTEGER or LONGINT) if 'v' is an integer, otherwise it is the unique enumeration type that contains v. Subranges may have base type LONGINT. FIRST, LAST and NUMBER work for LONGINT. LONGINT is predeclared. Should the subrange [0..LAST(LONGINT)] be given a predeclared name? LONGCARD? -Array Types: Arrays may only be indexed by ordinals having an underlying INTEGER base type. [Otherwise, it will be difficult deciding the index type for open arrays.] -Set Types: It seems reasonable that SET OF Base, where the base type for Base is LONGINT, should be allowed. The restrictons on the number of elements in the base set remain (i.e., SET OF [0L..1023L] for elements having base type LONGINT will be practical, but not SET OF LONGINT). -Subtyping Rules: These remain the same for ordinals having LONGINT base type. 4. STATEMENTS. -Assignment: Since INTEGER and LONGINT have different base types they are not assignable. -For: FOR statements will function with LONGINT-based index types: FOR id := first TO last BY step DO S END where 'id' is an identifier, 'first' and 'last' are ordinal expressions with the same base type (e.g., LONGINT), step is an integer-valued expression of type INTEGER or LONGINT and S is a statement. If omitted 'step' defaults to 1 or 1L, depending on the base type of the loop bounds 'first' and 'last'. If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it should be rewritten as a WHILE loop to avoid overflow. -Case: CASE statements may take an expression whose type is an ordinal type with base type LONGINT. -Inc and Dec: INC and DEC function for both INTEGER-based and LONGINT-based ordinals. 7. EXPRESSIONS -Conventions for describing operations: The class 'Integer' will be used to describe the type class consisting of both INTEGER and LONGINT (similar to the use of 'Float'). -Numeric literals: Numeric literals denote constant non-negative integers or reals. The types of these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. A literal LONGINT has the same form as a literal INTEGER, except that it is suffixed with the character 'L'. Thus the LONGINT having value zero would be written '0L'. Moreover, if no explicit base is present, the value of the literal must be at most LAST(LONGINT). If an explicit base is present, the value of the literal must be less than '2^Long.Size', and its interpretation uses the convention of the 'Long' interface. -Arithmetic operations: We adjust the arithmetic operations as follows, where the type class 'Integer' can be one of INTEGER or LONGINT, FloatType represents the type of a type variable taking one of the values REAL, LONGREAL, or EXTENDED, and IntType represents the type of a type variable taking one of the values INTEGER or LONGINT. prefix + (x: Integer) : Integer (x: Float) : Float infix + (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set prefix - (x: Integer) : Integer (x: Float) : Float infix - (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set infix * (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set infix / (x,y: Float) : Float (x,y: Set) : Set infix DIV (x,y: Integer): Integer infix MOD (x,y: Integer): Integer (x,y: Float) : Float ABS (x: Integer) : Integer (x: Float) : Float FLOAT (x: Integer; T: FloatType := REAL): T (x: Float; T: FloatType := REAL): T FLOOR (x: Float; T: IntType := INTEGER) : T CEILING (x: Float; T: IntType := INTEGER) : T ROUND (r: Float; T: IntType := INTEGER) : T TRUNC (r: Float; T: IntType := INTEGER) : T MAX, MIN (x,y: Ordinal) : Ordinal (x,y: Float) : Float -Relations These functions as expected for LONGINT. -Type operations ORD (element: Ordinal): Integer VAL (i: Integer; T: OrdinalType): T These function as expected, except that ORD returns INTEGER for elements of enumeration types. Otherwise, ORD returns an integer of the same base type as the element. Similarly, for VAL, if T is an enumeration type, then i must be an INTEGER. Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then ORD(n) = VAL(n, T: IntType): = n It is a static error if 'n' is not of type 'T'. NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = LONGINT (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT (A: FixedArrayType): CARDINAL (a: Array) : CARDINAL FIRST (T: OrdinalType) : BaseType(T) (T: FloatType) : T (A: FixedArrayType): BaseType(IndexType(A)) (a: Array) : BaseType(IndexType(a)) LAST (T: OrdinalType) : BaseType(T) (T: FloatType) : T (A: FixedArrayType): BaseType(IndexType(A)) (a: Array) : BaseType(IndexType(a)) BITSIZE (x: Any) : CARDINAL (T: Type): CARDINAL BYTESIZE (x: Any) : CARDINAL (T: Type): CARDINAL ADRSIZE (x: Any) : CARDINAL (T: Type): CARDINAL 9. REQUIRED INTERFACES There is an additional required interface 'Long', analogous to 'Word' except that Long.T = LONGINT On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> My LONGINT implementation addresses many of your concerns. The >> LONGINT space is segregated from the INT space. I want to come >> up with an implementation that also permits ordinals based on >> LONGINT in addition to the current system of ordinals based on >> INTEGER. This requires revisiting the language spec and pushing >> through the implications. I'm going to look at that briefly >> before moving on to fixing user-level threading for all targets. > > By "ordinals", do you mean enumerations? Subranges?. In the language > definition, ordinals refers to both the above, plus INTEGER, with > CHAR and > BOOLEAN being enumerations. > > It is hard to image a use for enumerations with more than 2^32 values. > As I recall, I was thinking this would add quite a bit of > complexity to > the language for negligible benefit. > > Subranges of LONGINT seem entirely useful and make for consistency. > From a language definition standpoint, I think these just about fall > into place with very little change. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 21:31:54 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:31:54 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> Message-ID: Yes, I will make bootstrapped compilers available in the usual place. Note that as soon as I check in the updates to CVS then old bootstrap compilers will no longer be able to compile m3core, since it mentions the type LONGINT in the Long.i3 interface. Building with a compiler that supports LONGINT will involve the following bootstrap process: 1. Build and ship the old versions of m3core and libm3. 2. Build and ship m3middle, m3linker, m3front, m3quake, cm3 3. Build and ship the new version of the sources via do-cm3-std.sh using the compiler from step 2 (in INSTALL_ROOT/pkg/cm3/TARGET/cm3). Easiest way to do this is to "export CM3=INSTALL_ROOT/pkg/cm3/ TARGET/cm3" (where INSTALL_ROOT and TARGET match your system) and then execute: do-cm3-std.sh realclean do-cm3-std.sh buildship from the scripts sub-directory of a clean CVS checkout I'll send a message once I have compilers available on my ftp site. On Jul 19, 2007, at 2:41 PM, Darko wrote: > This really is great stuff Tony, thanks for doing the hard yards. > Will you be making a build of this available in your usual spot? > > I'd like to try this out for a while and look for creative ways to > make it break (no offence intended) and get a feel for where it > needs to be extended. In the spirit of the M3 founding fathers, I > think we need some experience with this and then look at the > simplest and smallest change we can do to support what is missing. > > Cheers, > Darko. > > > On 19/07/2007, at 5:31 PM, Tony Hosking wrote: > >> My LONGINT implementation addresses many of your concerns. The >> LONGINT space is segregated from the INT space. I want to come up >> with an implementation that also permits ordinals based on LONGINT >> in addition to the current system of ordinals based on INTEGER. >> This requires revisiting the language spec and pushing through the >> implications. I'm going to look at that briefly before moving on >> to fixing user-level threading for all targets. >> >> On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: >> >>> Hello everyone, >>> >>> I have read the various proposals for supporting integers of >>> different >>> bit sizes and am getting a little worried that they are running >>> away from the traditional Modula-3 simplicity. As far as I know, >>> there is very little in Modula-3 that depends on the actual size >>> in bits of INTEGERs and CARDINALs. It doesn't seem to me to make >>> much sense to introduce types like Int32.T and Int64.T and then >>> make the definition Int32.T = INTEGER (on one platform) and Int64.T >>> = INTEGER (on another platform). I'm wondering if it would instead >>> be possible to introduce a new group of types in the sense that >>> Modula-3 now has integer types and floating-point types, and call >>> these types "fixed width" or "specified width" types. Conversions >>> between these types and INTEGER or CARDINAL would have to be done >>> using functions (operators) that are the analogs of FLOAT, ROUND, >>> etc. Standard arithmetic operators would be overloaded just like >>> they are today for integers and floating-point numbers. Am I just >>> duplicating someone else's proposal here? Perhaps this proposal >>> doesn't address everything one might want to do with these extended- >>> size types? >>> >>> Maybe I am just dreaming about getting Modula-3 running on a >>> DECsystem-20 with 36-bit integers...with pickles that are >>> interchangeable >>> with i386 pickles, of course. >>> >>> What do people want to do with these extended-size types anyhow? >>> It seems good to me that INTEGER is the largest type that I can >>> expect my processor to calculate efficiently with. I would use >>> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible >>> and write my code to be flexible about the BYTE/BITSIZE... but OK, >>> I can see the rationale for hiding all this in the compiler (and >>> inlining everything) in the few cases where I might want four- >>> function >>> arithmetic on (specifically) 64- or 128-bit integers. >>> >>> Mika >>> >>> Darko writes: >>>> Actually I stated the wrong reason for that one, it's really an >>>> argument against mixed integer assignment. >>>> >>>> And saying that it looks right from the C/C++ point of view is >>>> pretty >>>> damning... >>>> >>>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >>>> >>>>> Mail from unsubscribed address forwarded to the list... >>>>> ---------------------------- Original Message >>>>> ---------------------------- >>>>> Subject: Re: A nonnative 64-bit language proposal >>>>> From: hendrik at topoi.pooq.com >>>>> Date: Wed, October 25, 2006 14:22 >>>>> To: m3devel at elegosoft.com >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>> ---- >>>>> >>>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>>>> >>>>>> For your example to compute as an integer even if that >>>>>> overflows and >>>>>> it wouldn't as a longint seems right from my C/C++ point of view. >>>>> >>>>> I've always thought C/C++ were badly wrong on this one, even >>>>> from their own archaic low-level machine-oriented viewpoint. >>>>> Most computers have integer multiply instructions that return a >>>>> double-length product. >>>>> >>>>> -- hendrik >>>>> >>>>> >> From hosking at cs.purdue.edu Thu Jul 19 21:44:18 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:44:18 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469F7BAD.1E75.00D7.1@scires.com> References: <469F7BAD.1E75.00D7.1@scires.com> Message-ID: <7C096B2E-9366-4CC0-A03D-B06BFAF40FF8@cs.purdue.edu> On Jul 19, 2007, at 2:56 PM, Randy Coleburn wrote: > Tony: > > I'd like to better understand the implications of your change as I > do use LONGINT as an index in some applications. In that case, what is the index type of an open array: ARRAY OF X? I assume that dope vectors for open arrays will need to indicate the index type. Moreover, code compiled to manipulate ARRAY OF X will need to cope with dynamically-determined index types. My inclination is to avoid this pain by prohibiting ordinals with base type LONGINT from being used as the index type for arrays. > > 1. On a computer with a 32-bit word size, will LONGINT be 32 bits > or 64 bits? LONGINT will be the same as C "long long" which is 64 bits on a 32- bit machine. INTEGER will continue to be the same as C "long" which is 32 bits on a 32-bit machine. On a 64-bit machine, both INTEGER and LONGINT will be 64 bits. > 2. I assume on a computer with a 64-bit word size, LONGINT will be > 64 bits. Is there an option to get a 32-bit integer on these > machines? What's wrong with "BITS 32 FOR [-16_80000000 .. 16_7fffffff]"? > 3. Would it make sense to keep LONGINT at 32-bits and make a new > type, say LONGINT64, at 64-bits? I don't think anyone should make any assumption in portable code about LONGINT and INTEGER other than that BITSIZE(INTEGER) <= BITSIZE(LONGINT) When assuming a given target I think it is reasonable to assume: BITSIZE(INTEGER) = sizeof (long) BITSIZE(LONGINT) = sizeof (long long) so that we have a convenient mapping to C header files and interfaces. > > Regards, > Randy > > Randy C. Coleburn > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." > > >>> Tony Hosking 7/18/2007 11:53 PM >>> > I've successfully bootstrapped a CM3 compiler that supports LONGINT > as a 64-bit integer type (equivalent to "long long" in C) in addition > to INTEGER (same as "long" in C). This will be useful for > simplifying interfaces to C library routines that expect to be able > to treat 64-bit integers such as "off_t" ! for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type > (I'm not sure this would ever be a good idea) so it cannot be used to > index arrays, define enumerations etc., though the simple operations > ABS, MAX, MIN, addition, comparisons, MOD, multiplication, > subtraction, assignment, are all supported. This includes changes to > m3core (with support for Long.T similar to Word.T, plus RTTipe and > RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, > m3front, and the gcc-based compiler backend. There is still work > that needs to be done to support and test all the other M3 tools such > as network objects, etc., with support and testing needed in m3tk for > the new type, as well as in other tools like m3browser. > > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head jus! t so that it gets some > testing, but perhaps that is prematur e. I can confirm a complete > bootstrap via "do-cm3-std.sh" that appears to produce perfectly > functional executables, including mentor, etc. > > From darko at darko.org Thu Jul 19 22:23:27 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 22:23:27 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> Message-ID: <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> Have I missed something or is there no way to assign between INTEGER and LONGINT? Is there an explicit conversion function that I've overlooked? Would assignment be so bad here since there would be an implicit range check, much like when you assign between two overlapping subranges? In a sense these two types are integer subranges of an abstract integer type containing all integers. n 19/07/2007, at 9:23 PM, Tony Hosking wrote: > Here are my notes from a run through the language spec. Next step > is to flesh out the additional bits in the compiler beyond what I > announced yesterday. I would appreciate any feedback you can give > as I look into this. > > 3. TYPES > > -Ordinal Types: > > There are three kinds of ordinal types: enumerations, subranges, and > integers. There are two integer types, which in order of > increasing range and > precision are INTEGER and LONGINT. > > The base type of an ordinal value 'v' is its type (INTEGER or > LONGINT) if 'v' > is an integer, otherwise it is the unique enumeration type that > contains v. > > Subranges may have base type LONGINT. > > FIRST, LAST and NUMBER work for LONGINT. > > LONGINT is predeclared. > > Should the subrange [0..LAST(LONGINT)] be given a predeclared > name? LONGCARD? > > -Array Types: > > Arrays may only be indexed by ordinals having an underlying INTEGER > base type. > [Otherwise, it will be difficult deciding the index type for open > arrays.] > > -Set Types: > > It seems reasonable that SET OF Base, where the base type for Base > is LONGINT, > should be allowed. The restrictons on the number of elements in > the base set > remain (i.e., SET OF [0L..1023L] for elements having base type > LONGINT will be > practical, but not SET OF LONGINT). > > -Subtyping Rules: > > These remain the same for ordinals having LONGINT base type. > > > 4. STATEMENTS. > > -Assignment: > > Since INTEGER and LONGINT have different base types they are not > assignable. > > -For: > > FOR statements will function with LONGINT-based index types: > > FOR id := first TO last BY step DO S END > > where 'id' is an identifier, 'first' and 'last' are ordinal > expressions with > the same base type (e.g., LONGINT), step is an integer-valued > expression of > type INTEGER or LONGINT and S is a statement. If omitted 'step' > defaults to 1 > or 1L, depending on the base type of the loop bounds 'first' and > 'last'. > > If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it > should be rewritten as a WHILE loop to avoid overflow. > > -Case: > > CASE statements may take an expression whose type is an ordinal > type with base > type LONGINT. > > -Inc and Dec: > > INC and DEC function for both INTEGER-based and LONGINT-based > ordinals. > > 7. EXPRESSIONS > > -Conventions for describing operations: > > The class 'Integer' will be used to describe the type class > consisting of both > INTEGER and LONGINT (similar to the use of 'Float'). > > -Numeric literals: > > Numeric literals denote constant non-negative integers or reals. > The types of > these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. > > A literal LONGINT has the same form as a literal INTEGER, except > that it is > suffixed with the character 'L'. Thus the LONGINT having value > zero would be > written '0L'. Moreover, if no explicit base is present, the value > of the > literal must be at most LAST(LONGINT). If an explicit base is > present, the > value of the literal must be less than '2^Long.Size', and its > interpretation > uses the convention of the 'Long' interface. > > -Arithmetic operations: > > We adjust the arithmetic operations as follows, where the type > class 'Integer' > can be one of INTEGER or LONGINT, FloatType represents the type of > a type > variable taking one of the values REAL, LONGREAL, or EXTENDED, and > IntType > represents the type of a type variable taking one of the values > INTEGER or LONGINT. > > prefix + (x: Integer) : Integer > (x: Float) : Float > > infix + (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > prefix - (x: Integer) : Integer > (x: Float) : Float > > infix - (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > infix * (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > infix / (x,y: Float) : Float > (x,y: Set) : Set > > infix DIV (x,y: Integer): Integer > > infix MOD (x,y: Integer): Integer > (x,y: Float) : Float > > ABS (x: Integer) : Integer > (x: Float) : Float > > FLOAT (x: Integer; T: FloatType := REAL): T > (x: Float; T: FloatType := REAL): T > > FLOOR (x: Float; T: IntType := INTEGER) : T > CEILING (x: Float; T: IntType := INTEGER) : T > > ROUND (r: Float; T: IntType := INTEGER) : T > TRUNC (r: Float; T: IntType := INTEGER) : T > > MAX, MIN (x,y: Ordinal) : Ordinal > (x,y: Float) : Float > > -Relations > > These functions as expected for LONGINT. > > -Type operations > > ORD (element: Ordinal): Integer > VAL (i: Integer; T: OrdinalType): T > > These function as expected, except that ORD returns INTEGER for > elements of > enumeration types. Otherwise, ORD returns an integer of the same > base type as > the element. Similarly, for VAL, if T is an enumeration type, then > i must be > an INTEGER. > > Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then > > ORD(n) = VAL(n, T: IntType): = n > > It is a static error if 'n' is not of type 'T'. > > NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = > LONGINT > (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT > (A: FixedArrayType): CARDINAL > (a: Array) : CARDINAL > > FIRST (T: OrdinalType) : BaseType(T) > (T: FloatType) : T > (A: FixedArrayType): BaseType(IndexType(A)) > (a: Array) : BaseType(IndexType(a)) > LAST (T: OrdinalType) : BaseType(T) > (T: FloatType) : T > (A: FixedArrayType): BaseType(IndexType(A)) > (a: Array) : BaseType(IndexType(a)) > > BITSIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > BYTESIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > ADRSIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > > 9. REQUIRED INTERFACES > > There is an additional required interface 'Long', analogous to > 'Word' except that > > Long.T = LONGINT > > > On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: > >> >> >> Tony Hosking wrote: >>> My LONGINT implementation addresses many of your concerns. The >>> LONGINT space is segregated from the INT space. I want to come >>> up with an implementation that also permits ordinals based on >>> LONGINT in addition to the current system of ordinals based on >>> INTEGER. This requires revisiting the language spec and pushing >>> through the implications. I'm going to look at that briefly >>> before moving on to fixing user-level threading for all targets. >> >> By "ordinals", do you mean enumerations? Subranges?. In the >> language >> definition, ordinals refers to both the above, plus INTEGER, with >> CHAR and >> BOOLEAN being enumerations. >> >> It is hard to image a use for enumerations with more than 2^32 >> values. >> As I recall, I was thinking this would add quite a bit of >> complexity to >> the language for negligible benefit. >> >> Subranges of LONGINT seem entirely useful and make for consistency. >> From a language definition standpoint, I think these just about fall >> into place with very little change. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > From hosking at cs.purdue.edu Thu Jul 19 22:26:38 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 16:26:38 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> Message-ID: <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> This is a good question. I would assume that conversion must be explicit to fit with the M3 philosophy. It would make sense to have a conversion operation that performs the appropriate range check? Any ideas for a name for the operation. On Jul 19, 2007, at 4:23 PM, Darko wrote: > Have I missed something or is there no way to assign between > INTEGER and LONGINT? Is there an explicit conversion function that > I've overlooked? Would assignment be so bad here since there would > be an implicit range check, much like when you assign between two > overlapping subranges? In a sense these two types are integer > subranges of an abstract integer type containing all integers. > > > n 19/07/2007, at 9:23 PM, Tony Hosking wrote: > >> Here are my notes from a run through the language spec. Next step >> is to flesh out the additional bits in the compiler beyond what I >> announced yesterday. I would appreciate any feedback you can give >> as I look into this. >> >> 3. TYPES >> >> -Ordinal Types: >> >> There are three kinds of ordinal types: enumerations, subranges, and >> integers. There are two integer types, which in order of >> increasing range and >> precision are INTEGER and LONGINT. >> >> The base type of an ordinal value 'v' is its type (INTEGER or >> LONGINT) if 'v' >> is an integer, otherwise it is the unique enumeration type that >> contains v. >> >> Subranges may have base type LONGINT. >> >> FIRST, LAST and NUMBER work for LONGINT. >> >> LONGINT is predeclared. >> >> Should the subrange [0..LAST(LONGINT)] be given a predeclared >> name? LONGCARD? >> >> -Array Types: >> >> Arrays may only be indexed by ordinals having an underlying >> INTEGER base type. >> [Otherwise, it will be difficult deciding the index type for open >> arrays.] >> >> -Set Types: >> >> It seems reasonable that SET OF Base, where the base type for Base >> is LONGINT, >> should be allowed. The restrictons on the number of elements in >> the base set >> remain (i.e., SET OF [0L..1023L] for elements having base type >> LONGINT will be >> practical, but not SET OF LONGINT). >> >> -Subtyping Rules: >> >> These remain the same for ordinals having LONGINT base type. >> >> >> 4. STATEMENTS. >> >> -Assignment: >> >> Since INTEGER and LONGINT have different base types they are not >> assignable. >> >> -For: >> >> FOR statements will function with LONGINT-based index types: >> >> FOR id := first TO last BY step DO S END >> >> where 'id' is an identifier, 'first' and 'last' are ordinal >> expressions with >> the same base type (e.g., LONGINT), step is an integer-valued >> expression of >> type INTEGER or LONGINT and S is a statement. If omitted 'step' >> defaults to 1 >> or 1L, depending on the base type of the loop bounds 'first' and >> 'last'. >> >> If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it >> should be rewritten as a WHILE loop to avoid overflow. >> >> -Case: >> >> CASE statements may take an expression whose type is an ordinal >> type with base >> type LONGINT. >> >> -Inc and Dec: >> >> INC and DEC function for both INTEGER-based and LONGINT-based >> ordinals. >> >> 7. EXPRESSIONS >> >> -Conventions for describing operations: >> >> The class 'Integer' will be used to describe the type class >> consisting of both >> INTEGER and LONGINT (similar to the use of 'Float'). >> >> -Numeric literals: >> >> Numeric literals denote constant non-negative integers or reals. >> The types of >> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >> >> A literal LONGINT has the same form as a literal INTEGER, except >> that it is >> suffixed with the character 'L'. Thus the LONGINT having value >> zero would be >> written '0L'. Moreover, if no explicit base is present, the value >> of the >> literal must be at most LAST(LONGINT). If an explicit base is >> present, the >> value of the literal must be less than '2^Long.Size', and its >> interpretation >> uses the convention of the 'Long' interface. >> >> -Arithmetic operations: >> >> We adjust the arithmetic operations as follows, where the type >> class 'Integer' >> can be one of INTEGER or LONGINT, FloatType represents the type of >> a type >> variable taking one of the values REAL, LONGREAL, or EXTENDED, and >> IntType >> represents the type of a type variable taking one of the values >> INTEGER or LONGINT. >> >> prefix + (x: Integer) : Integer >> (x: Float) : Float >> >> infix + (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> prefix - (x: Integer) : Integer >> (x: Float) : Float >> >> infix - (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix * (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix / (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix DIV (x,y: Integer): Integer >> >> infix MOD (x,y: Integer): Integer >> (x,y: Float) : Float >> >> ABS (x: Integer) : Integer >> (x: Float) : Float >> >> FLOAT (x: Integer; T: FloatType := REAL): T >> (x: Float; T: FloatType := REAL): T >> >> FLOOR (x: Float; T: IntType := INTEGER) : T >> CEILING (x: Float; T: IntType := INTEGER) : T >> >> ROUND (r: Float; T: IntType := INTEGER) : T >> TRUNC (r: Float; T: IntType := INTEGER) : T >> >> MAX, MIN (x,y: Ordinal) : Ordinal >> (x,y: Float) : Float >> >> -Relations >> >> These functions as expected for LONGINT. >> >> -Type operations >> >> ORD (element: Ordinal): Integer >> VAL (i: Integer; T: OrdinalType): T >> >> These function as expected, except that ORD returns INTEGER for >> elements of >> enumeration types. Otherwise, ORD returns an integer of the same >> base type as >> the element. Similarly, for VAL, if T is an enumeration type, >> then i must be >> an INTEGER. >> >> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >> >> ORD(n) = VAL(n, T: IntType): = n >> >> It is a static error if 'n' is not of type 'T'. >> >> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = >> LONGINT >> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >> (A: FixedArrayType): CARDINAL >> (a: Array) : CARDINAL >> >> FIRST (T: OrdinalType) : BaseType(T) >> (T: FloatType) : T >> (A: FixedArrayType): BaseType(IndexType(A)) >> (a: Array) : BaseType(IndexType(a)) >> LAST (T: OrdinalType) : BaseType(T) >> (T: FloatType) : T >> (A: FixedArrayType): BaseType(IndexType(A)) >> (a: Array) : BaseType(IndexType(a)) >> >> BITSIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> BYTESIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> ADRSIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> >> 9. REQUIRED INTERFACES >> >> There is an additional required interface 'Long', analogous to >> 'Word' except that >> >> Long.T = LONGINT >> >> >> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >> >>> >>> >>> Tony Hosking wrote: >>>> My LONGINT implementation addresses many of your concerns. The >>>> LONGINT space is segregated from the INT space. I want to come >>>> up with an implementation that also permits ordinals based on >>>> LONGINT in addition to the current system of ordinals based on >>>> INTEGER. This requires revisiting the language spec and >>>> pushing through the implications. I'm going to look at that >>>> briefly before moving on to fixing user-level threading for all >>>> targets. >>> >>> By "ordinals", do you mean enumerations? Subranges?. In the >>> language >>> definition, ordinals refers to both the above, plus INTEGER, with >>> CHAR and >>> BOOLEAN being enumerations. >>> >>> It is hard to image a use for enumerations with more than 2^32 >>> values. >>> As I recall, I was thinking this would add quite a bit of >>> complexity to >>> the language for negligible benefit. >>> >>> Subranges of LONGINT seem entirely useful and make for consistency. >>> From a language definition standpoint, I think these just about fall >>> into place with very little change. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu >> From darko at darko.org Thu Jul 19 22:33:04 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 22:33:04 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> Message-ID: <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> I actually favour a implicit conversion, which for this particular case I think would be consistent with existing M3 behaviour. On 19/07/2007, at 10:26 PM, Tony Hosking wrote: > This is a good question. I would assume that conversion must be > explicit to fit with the M3 philosophy. It would make sense to > have a conversion operation that performs the appropriate range > check? Any ideas for a name for the operation. > > On Jul 19, 2007, at 4:23 PM, Darko wrote: > >> Have I missed something or is there no way to assign between >> INTEGER and LONGINT? Is there an explicit conversion function that >> I've overlooked? Would assignment be so bad here since there would >> be an implicit range check, much like when you assign between two >> overlapping subranges? In a sense these two types are integer >> subranges of an abstract integer type containing all integers. >> >> >> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >> >>> Here are my notes from a run through the language spec. Next >>> step is to flesh out the additional bits in the compiler beyond >>> what I announced yesterday. I would appreciate any feedback you >>> can give as I look into this. >>> >>> 3. TYPES >>> >>> -Ordinal Types: >>> >>> There are three kinds of ordinal types: enumerations, subranges, and >>> integers. There are two integer types, which in order of >>> increasing range and >>> precision are INTEGER and LONGINT. >>> >>> The base type of an ordinal value 'v' is its type (INTEGER or >>> LONGINT) if 'v' >>> is an integer, otherwise it is the unique enumeration type that >>> contains v. >>> >>> Subranges may have base type LONGINT. >>> >>> FIRST, LAST and NUMBER work for LONGINT. >>> >>> LONGINT is predeclared. >>> >>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>> name? LONGCARD? >>> >>> -Array Types: >>> >>> Arrays may only be indexed by ordinals having an underlying >>> INTEGER base type. >>> [Otherwise, it will be difficult deciding the index type for open >>> arrays.] >>> >>> -Set Types: >>> >>> It seems reasonable that SET OF Base, where the base type for >>> Base is LONGINT, >>> should be allowed. The restrictons on the number of elements in >>> the base set >>> remain (i.e., SET OF [0L..1023L] for elements having base type >>> LONGINT will be >>> practical, but not SET OF LONGINT). >>> >>> -Subtyping Rules: >>> >>> These remain the same for ordinals having LONGINT base type. >>> >>> >>> 4. STATEMENTS. >>> >>> -Assignment: >>> >>> Since INTEGER and LONGINT have different base types they are not >>> assignable. >>> >>> -For: >>> >>> FOR statements will function with LONGINT-based index types: >>> >>> FOR id := first TO last BY step DO S END >>> >>> where 'id' is an identifier, 'first' and 'last' are ordinal >>> expressions with >>> the same base type (e.g., LONGINT), step is an integer-valued >>> expression of >>> type INTEGER or LONGINT and S is a statement. If omitted 'step' >>> defaults to 1 >>> or 1L, depending on the base type of the loop bounds 'first' and >>> 'last'. >>> >>> If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it >>> should be rewritten as a WHILE loop to avoid overflow. >>> >>> -Case: >>> >>> CASE statements may take an expression whose type is an ordinal >>> type with base >>> type LONGINT. >>> >>> -Inc and Dec: >>> >>> INC and DEC function for both INTEGER-based and LONGINT-based >>> ordinals. >>> >>> 7. EXPRESSIONS >>> >>> -Conventions for describing operations: >>> >>> The class 'Integer' will be used to describe the type class >>> consisting of both >>> INTEGER and LONGINT (similar to the use of 'Float'). >>> >>> -Numeric literals: >>> >>> Numeric literals denote constant non-negative integers or reals. >>> The types of >>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>> >>> A literal LONGINT has the same form as a literal INTEGER, except >>> that it is >>> suffixed with the character 'L'. Thus the LONGINT having value >>> zero would be >>> written '0L'. Moreover, if no explicit base is present, the >>> value of the >>> literal must be at most LAST(LONGINT). If an explicit base is >>> present, the >>> value of the literal must be less than '2^Long.Size', and its >>> interpretation >>> uses the convention of the 'Long' interface. >>> >>> -Arithmetic operations: >>> >>> We adjust the arithmetic operations as follows, where the type >>> class 'Integer' >>> can be one of INTEGER or LONGINT, FloatType represents the type >>> of a type >>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>> and IntType >>> represents the type of a type variable taking one of the values >>> INTEGER or LONGINT. >>> >>> prefix + (x: Integer) : Integer >>> (x: Float) : Float >>> >>> infix + (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> prefix - (x: Integer) : Integer >>> (x: Float) : Float >>> >>> infix - (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix * (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix / (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix DIV (x,y: Integer): Integer >>> >>> infix MOD (x,y: Integer): Integer >>> (x,y: Float) : Float >>> >>> ABS (x: Integer) : Integer >>> (x: Float) : Float >>> >>> FLOAT (x: Integer; T: FloatType := REAL): T >>> (x: Float; T: FloatType := REAL): T >>> >>> FLOOR (x: Float; T: IntType := INTEGER) : T >>> CEILING (x: Float; T: IntType := INTEGER) : T >>> >>> ROUND (r: Float; T: IntType := INTEGER) : T >>> TRUNC (r: Float; T: IntType := INTEGER) : T >>> >>> MAX, MIN (x,y: Ordinal) : Ordinal >>> (x,y: Float) : Float >>> >>> -Relations >>> >>> These functions as expected for LONGINT. >>> >>> -Type operations >>> >>> ORD (element: Ordinal): Integer >>> VAL (i: Integer; T: OrdinalType): T >>> >>> These function as expected, except that ORD returns INTEGER for >>> elements of >>> enumeration types. Otherwise, ORD returns an integer of the same >>> base type as >>> the element. Similarly, for VAL, if T is an enumeration type, >>> then i must be >>> an INTEGER. >>> >>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>> >>> ORD(n) = VAL(n, T: IntType): = n >>> >>> It is a static error if 'n' is not of type 'T'. >>> >>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) >>> = LONGINT >>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >>> (A: FixedArrayType): CARDINAL >>> (a: Array) : CARDINAL >>> >>> FIRST (T: OrdinalType) : BaseType(T) >>> (T: FloatType) : T >>> (A: FixedArrayType): BaseType(IndexType(A)) >>> (a: Array) : BaseType(IndexType(a)) >>> LAST (T: OrdinalType) : BaseType(T) >>> (T: FloatType) : T >>> (A: FixedArrayType): BaseType(IndexType(A)) >>> (a: Array) : BaseType(IndexType(a)) >>> >>> BITSIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> BYTESIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> ADRSIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> >>> 9. REQUIRED INTERFACES >>> >>> There is an additional required interface 'Long', analogous to >>> 'Word' except that >>> >>> Long.T = LONGINT >>> >>> >>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>> >>>> >>>> >>>> Tony Hosking wrote: >>>>> My LONGINT implementation addresses many of your concerns. >>>>> The LONGINT space is segregated from the INT space. I want to >>>>> come up with an implementation that also permits ordinals >>>>> based on LONGINT in addition to the current system of ordinals >>>>> based on INTEGER. This requires revisiting the language spec >>>>> and pushing through the implications. I'm going to look at >>>>> that briefly before moving on to fixing user-level threading >>>>> for all targets. >>>> >>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>> language >>>> definition, ordinals refers to both the above, plus INTEGER, >>>> with CHAR and >>>> BOOLEAN being enumerations. >>>> >>>> It is hard to image a use for enumerations with more than 2^32 >>>> values. >>>> As I recall, I was thinking this would add quite a bit of >>>> complexity to >>>> the language for negligible benefit. >>>> >>>> Subranges of LONGINT seem entirely useful and make for consistency. >>>> From a language definition standpoint, I think these just about >>>> fall >>>> into place with very little change. >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu >>> > From hosking at cs.purdue.edu Thu Jul 19 22:50:50 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 16:50:50 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: On Jul 19, 2007, at 4:33 PM, Darko wrote: > I actually favour a implicit conversion, which for this particular > case I think would be consistent with existing M3 behaviour. There is no implicit conversion for floats. The danger with implicit conversion for integers is that it would not be portable: you would get different behavior on different machines for the same code. Better to make the conversion explicit so that programmers are prepared for the range check to fail. > > > On 19/07/2007, at 10:26 PM, Tony Hosking wrote: > >> This is a good question. I would assume that conversion must be >> explicit to fit with the M3 philosophy. It would make sense to >> have a conversion operation that performs the appropriate range >> check? Any ideas for a name for the operation. >> >> On Jul 19, 2007, at 4:23 PM, Darko wrote: >> >>> Have I missed something or is there no way to assign between >>> INTEGER and LONGINT? Is there an explicit conversion function >>> that I've overlooked? Would assignment be so bad here since there >>> would be an implicit range check, much like when you assign >>> between two overlapping subranges? In a sense these two types are >>> integer subranges of an abstract integer type containing all >>> integers. >>> >>> >>> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >>> >>>> Here are my notes from a run through the language spec. Next >>>> step is to flesh out the additional bits in the compiler beyond >>>> what I announced yesterday. I would appreciate any feedback you >>>> can give as I look into this. >>>> >>>> 3. TYPES >>>> >>>> -Ordinal Types: >>>> >>>> There are three kinds of ordinal types: enumerations, subranges, >>>> and >>>> integers. There are two integer types, which in order of >>>> increasing range and >>>> precision are INTEGER and LONGINT. >>>> >>>> The base type of an ordinal value 'v' is its type (INTEGER or >>>> LONGINT) if 'v' >>>> is an integer, otherwise it is the unique enumeration type that >>>> contains v. >>>> >>>> Subranges may have base type LONGINT. >>>> >>>> FIRST, LAST and NUMBER work for LONGINT. >>>> >>>> LONGINT is predeclared. >>>> >>>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>>> name? LONGCARD? >>>> >>>> -Array Types: >>>> >>>> Arrays may only be indexed by ordinals having an underlying >>>> INTEGER base type. >>>> [Otherwise, it will be difficult deciding the index type for >>>> open arrays.] >>>> >>>> -Set Types: >>>> >>>> It seems reasonable that SET OF Base, where the base type for >>>> Base is LONGINT, >>>> should be allowed. The restrictons on the number of elements in >>>> the base set >>>> remain (i.e., SET OF [0L..1023L] for elements having base type >>>> LONGINT will be >>>> practical, but not SET OF LONGINT). >>>> >>>> -Subtyping Rules: >>>> >>>> These remain the same for ordinals having LONGINT base type. >>>> >>>> >>>> 4. STATEMENTS. >>>> >>>> -Assignment: >>>> >>>> Since INTEGER and LONGINT have different base types they are not >>>> assignable. >>>> >>>> -For: >>>> >>>> FOR statements will function with LONGINT-based index types: >>>> >>>> FOR id := first TO last BY step DO S END >>>> >>>> where 'id' is an identifier, 'first' and 'last' are ordinal >>>> expressions with >>>> the same base type (e.g., LONGINT), step is an integer-valued >>>> expression of >>>> type INTEGER or LONGINT and S is a statement. If omitted 'step' >>>> defaults to 1 >>>> or 1L, depending on the base type of the loop bounds 'first' and >>>> 'last'. >>>> >>>> If the upper bound of the loop is LAST(INTEGER) or LAST >>>> (LONGINT), it >>>> should be rewritten as a WHILE loop to avoid overflow. >>>> >>>> -Case: >>>> >>>> CASE statements may take an expression whose type is an ordinal >>>> type with base >>>> type LONGINT. >>>> >>>> -Inc and Dec: >>>> >>>> INC and DEC function for both INTEGER-based and LONGINT-based >>>> ordinals. >>>> >>>> 7. EXPRESSIONS >>>> >>>> -Conventions for describing operations: >>>> >>>> The class 'Integer' will be used to describe the type class >>>> consisting of both >>>> INTEGER and LONGINT (similar to the use of 'Float'). >>>> >>>> -Numeric literals: >>>> >>>> Numeric literals denote constant non-negative integers or reals. >>>> The types of >>>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>>> >>>> A literal LONGINT has the same form as a literal INTEGER, except >>>> that it is >>>> suffixed with the character 'L'. Thus the LONGINT having value >>>> zero would be >>>> written '0L'. Moreover, if no explicit base is present, the >>>> value of the >>>> literal must be at most LAST(LONGINT). If an explicit base is >>>> present, the >>>> value of the literal must be less than '2^Long.Size', and its >>>> interpretation >>>> uses the convention of the 'Long' interface. >>>> >>>> -Arithmetic operations: >>>> >>>> We adjust the arithmetic operations as follows, where the type >>>> class 'Integer' >>>> can be one of INTEGER or LONGINT, FloatType represents the type >>>> of a type >>>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>>> and IntType >>>> represents the type of a type variable taking one of the values >>>> INTEGER or LONGINT. >>>> >>>> prefix + (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> infix + (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> prefix - (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> infix - (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix * (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix / (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix DIV (x,y: Integer): Integer >>>> >>>> infix MOD (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> >>>> ABS (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> FLOAT (x: Integer; T: FloatType := REAL): T >>>> (x: Float; T: FloatType := REAL): T >>>> >>>> FLOOR (x: Float; T: IntType := INTEGER) : T >>>> CEILING (x: Float; T: IntType := INTEGER) : T >>>> >>>> ROUND (r: Float; T: IntType := INTEGER) : T >>>> TRUNC (r: Float; T: IntType := INTEGER) : T >>>> >>>> MAX, MIN (x,y: Ordinal) : Ordinal >>>> (x,y: Float) : Float >>>> >>>> -Relations >>>> >>>> These functions as expected for LONGINT. >>>> >>>> -Type operations >>>> >>>> ORD (element: Ordinal): Integer >>>> VAL (i: Integer; T: OrdinalType): T >>>> >>>> These function as expected, except that ORD returns INTEGER for >>>> elements of >>>> enumeration types. Otherwise, ORD returns an integer of the >>>> same base type as >>>> the element. Similarly, for VAL, if T is an enumeration type, >>>> then i must be >>>> an INTEGER. >>>> >>>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>>> >>>> ORD(n) = VAL(n, T: IntType): = n >>>> >>>> It is a static error if 'n' is not of type 'T'. >>>> >>>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) >>>> = LONGINT >>>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >>>> (A: FixedArrayType): CARDINAL >>>> (a: Array) : CARDINAL >>>> >>>> FIRST (T: OrdinalType) : BaseType(T) >>>> (T: FloatType) : T >>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>> (a: Array) : BaseType(IndexType(a)) >>>> LAST (T: OrdinalType) : BaseType(T) >>>> (T: FloatType) : T >>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>> (a: Array) : BaseType(IndexType(a)) >>>> >>>> BITSIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> BYTESIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> ADRSIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> >>>> 9. REQUIRED INTERFACES >>>> >>>> There is an additional required interface 'Long', analogous to >>>> 'Word' except that >>>> >>>> Long.T = LONGINT >>>> >>>> >>>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>>> My LONGINT implementation addresses many of your concerns. >>>>>> The LONGINT space is segregated from the INT space. I want >>>>>> to come up with an implementation that also permits ordinals >>>>>> based on LONGINT in addition to the current system of >>>>>> ordinals based on INTEGER. This requires revisiting the >>>>>> language spec and pushing through the implications. I'm >>>>>> going to look at that briefly before moving on to fixing user- >>>>>> level threading for all targets. >>>>> >>>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>>> language >>>>> definition, ordinals refers to both the above, plus INTEGER, >>>>> with CHAR and >>>>> BOOLEAN being enumerations. >>>>> >>>>> It is hard to image a use for enumerations with more than 2^32 >>>>> values. >>>>> As I recall, I was thinking this would add quite a bit of >>>>> complexity to >>>>> the language for negligible benefit. >>>>> >>>>> Subranges of LONGINT seem entirely useful and make for >>>>> consistency. >>>>> From a language definition standpoint, I think these just about >>>>> fall >>>>> into place with very little change. >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu >>>> >> From darko at darko.org Thu Jul 19 23:23:35 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 23:23:35 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: I think INT and LONG seem pretty intuitive. INT(l: LONGINT): INTEGER; LONG(i: INTEGER): LONGINT; But back on the point, range check failures are a runtime phenomena, so they are an issue at anytime. On 19/07/2007, at 10:50 PM, Tony Hosking wrote: > On Jul 19, 2007, at 4:33 PM, Darko wrote: > >> I actually favour a implicit conversion, which for this particular >> case I think would be consistent with existing M3 behaviour. > > There is no implicit conversion for floats. The danger with > implicit conversion for integers is that it would not be portable: > you would get different behavior on different machines for the same > code. Better to make the conversion explicit so that programmers > are prepared for the range check to fail. > >> >> >> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >> >>> This is a good question. I would assume that conversion must be >>> explicit to fit with the M3 philosophy. It would make sense to >>> have a conversion operation that performs the appropriate range >>> check? Any ideas for a name for the operation. >>> >>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>> >>>> Have I missed something or is there no way to assign between >>>> INTEGER and LONGINT? Is there an explicit conversion function >>>> that I've overlooked? Would assignment be so bad here since >>>> there would be an implicit range check, much like when you >>>> assign between two overlapping subranges? In a sense these two >>>> types are integer subranges of an abstract integer type >>>> containing all integers. >>>> >>>> >>>> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >>>> >>>>> Here are my notes from a run through the language spec. Next >>>>> step is to flesh out the additional bits in the compiler beyond >>>>> what I announced yesterday. I would appreciate any feedback >>>>> you can give as I look into this. >>>>> >>>>> 3. TYPES >>>>> >>>>> -Ordinal Types: >>>>> >>>>> There are three kinds of ordinal types: enumerations, >>>>> subranges, and >>>>> integers. There are two integer types, which in order of >>>>> increasing range and >>>>> precision are INTEGER and LONGINT. >>>>> >>>>> The base type of an ordinal value 'v' is its type (INTEGER or >>>>> LONGINT) if 'v' >>>>> is an integer, otherwise it is the unique enumeration type that >>>>> contains v. >>>>> >>>>> Subranges may have base type LONGINT. >>>>> >>>>> FIRST, LAST and NUMBER work for LONGINT. >>>>> >>>>> LONGINT is predeclared. >>>>> >>>>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>>>> name? LONGCARD? >>>>> >>>>> -Array Types: >>>>> >>>>> Arrays may only be indexed by ordinals having an underlying >>>>> INTEGER base type. >>>>> [Otherwise, it will be difficult deciding the index type for >>>>> open arrays.] >>>>> >>>>> -Set Types: >>>>> >>>>> It seems reasonable that SET OF Base, where the base type for >>>>> Base is LONGINT, >>>>> should be allowed. The restrictons on the number of elements >>>>> in the base set >>>>> remain (i.e., SET OF [0L..1023L] for elements having base type >>>>> LONGINT will be >>>>> practical, but not SET OF LONGINT). >>>>> >>>>> -Subtyping Rules: >>>>> >>>>> These remain the same for ordinals having LONGINT base type. >>>>> >>>>> >>>>> 4. STATEMENTS. >>>>> >>>>> -Assignment: >>>>> >>>>> Since INTEGER and LONGINT have different base types they are >>>>> not assignable. >>>>> >>>>> -For: >>>>> >>>>> FOR statements will function with LONGINT-based index types: >>>>> >>>>> FOR id := first TO last BY step DO S END >>>>> >>>>> where 'id' is an identifier, 'first' and 'last' are ordinal >>>>> expressions with >>>>> the same base type (e.g., LONGINT), step is an integer-valued >>>>> expression of >>>>> type INTEGER or LONGINT and S is a statement. If omitted >>>>> 'step' defaults to 1 >>>>> or 1L, depending on the base type of the loop bounds 'first' >>>>> and 'last'. >>>>> >>>>> If the upper bound of the loop is LAST(INTEGER) or LAST >>>>> (LONGINT), it >>>>> should be rewritten as a WHILE loop to avoid overflow. >>>>> >>>>> -Case: >>>>> >>>>> CASE statements may take an expression whose type is an ordinal >>>>> type with base >>>>> type LONGINT. >>>>> >>>>> -Inc and Dec: >>>>> >>>>> INC and DEC function for both INTEGER-based and LONGINT-based >>>>> ordinals. >>>>> >>>>> 7. EXPRESSIONS >>>>> >>>>> -Conventions for describing operations: >>>>> >>>>> The class 'Integer' will be used to describe the type class >>>>> consisting of both >>>>> INTEGER and LONGINT (similar to the use of 'Float'). >>>>> >>>>> -Numeric literals: >>>>> >>>>> Numeric literals denote constant non-negative integers or >>>>> reals. The types of >>>>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>>>> >>>>> A literal LONGINT has the same form as a literal INTEGER, >>>>> except that it is >>>>> suffixed with the character 'L'. Thus the LONGINT having value >>>>> zero would be >>>>> written '0L'. Moreover, if no explicit base is present, the >>>>> value of the >>>>> literal must be at most LAST(LONGINT). If an explicit base is >>>>> present, the >>>>> value of the literal must be less than '2^Long.Size', and its >>>>> interpretation >>>>> uses the convention of the 'Long' interface. >>>>> >>>>> -Arithmetic operations: >>>>> >>>>> We adjust the arithmetic operations as follows, where the type >>>>> class 'Integer' >>>>> can be one of INTEGER or LONGINT, FloatType represents the type >>>>> of a type >>>>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>>>> and IntType >>>>> represents the type of a type variable taking one of the values >>>>> INTEGER or LONGINT. >>>>> >>>>> prefix + (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> infix + (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> prefix - (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> infix - (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix * (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix / (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix DIV (x,y: Integer): Integer >>>>> >>>>> infix MOD (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> >>>>> ABS (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> FLOAT (x: Integer; T: FloatType := REAL): T >>>>> (x: Float; T: FloatType := REAL): T >>>>> >>>>> FLOOR (x: Float; T: IntType := INTEGER) : T >>>>> CEILING (x: Float; T: IntType := INTEGER) : T >>>>> >>>>> ROUND (r: Float; T: IntType := INTEGER) : T >>>>> TRUNC (r: Float; T: IntType := INTEGER) : T >>>>> >>>>> MAX, MIN (x,y: Ordinal) : Ordinal >>>>> (x,y: Float) : Float >>>>> >>>>> -Relations >>>>> >>>>> These functions as expected for LONGINT. >>>>> >>>>> -Type operations >>>>> >>>>> ORD (element: Ordinal): Integer >>>>> VAL (i: Integer; T: OrdinalType): T >>>>> >>>>> These function as expected, except that ORD returns INTEGER for >>>>> elements of >>>>> enumeration types. Otherwise, ORD returns an integer of the >>>>> same base type as >>>>> the element. Similarly, for VAL, if T is an enumeration type, >>>>> then i must be >>>>> an INTEGER. >>>>> >>>>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>>>> >>>>> ORD(n) = VAL(n, T: IntType): = n >>>>> >>>>> It is a static error if 'n' is not of type 'T'. >>>>> >>>>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType >>>>> (T) = LONGINT >>>>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = >>>>> LONGINT >>>>> (A: FixedArrayType): CARDINAL >>>>> (a: Array) : CARDINAL >>>>> >>>>> FIRST (T: OrdinalType) : BaseType(T) >>>>> (T: FloatType) : T >>>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>>> (a: Array) : BaseType(IndexType(a)) >>>>> LAST (T: OrdinalType) : BaseType(T) >>>>> (T: FloatType) : T >>>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>>> (a: Array) : BaseType(IndexType(a)) >>>>> >>>>> BITSIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> BYTESIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> ADRSIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> >>>>> 9. REQUIRED INTERFACES >>>>> >>>>> There is an additional required interface 'Long', analogous to >>>>> 'Word' except that >>>>> >>>>> Long.T = LONGINT >>>>> >>>>> >>>>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>>>> >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>>> My LONGINT implementation addresses many of your concerns. >>>>>>> The LONGINT space is segregated from the INT space. I want >>>>>>> to come up with an implementation that also permits ordinals >>>>>>> based on LONGINT in addition to the current system of >>>>>>> ordinals based on INTEGER. This requires revisiting the >>>>>>> language spec and pushing through the implications. I'm >>>>>>> going to look at that briefly before moving on to fixing >>>>>>> user-level threading for all targets. >>>>>> >>>>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>>>> language >>>>>> definition, ordinals refers to both the above, plus INTEGER, >>>>>> with CHAR and >>>>>> BOOLEAN being enumerations. >>>>>> >>>>>> It is hard to image a use for enumerations with more than 2^32 >>>>>> values. >>>>>> As I recall, I was thinking this would add quite a bit of >>>>>> complexity to >>>>>> the language for negligible benefit. >>>>>> >>>>>> Subranges of LONGINT seem entirely useful and make for >>>>>> consistency. >>>>>> From a language definition standpoint, I think these just >>>>>> about fall >>>>>> into place with very little change. >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------- >>>>>> Rodney M. Bates, retired assistant professor >>>>>> Dept. of Computer Science, Wichita State University >>>>>> Wichita, KS 67260-0083 >>>>>> 316-978-3922 >>>>>> rodney.bates at wichita.edu >>>>> >>> > From rodney.bates at wichita.edu Thu Jul 19 23:33:28 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 16:33:28 -0500 Subject: [M3devel] LONGINT In-Reply-To: <469F7BAD.1E75.00D7.1@scires.com> References: <469F7BAD.1E75.00D7.1@scires.com> Message-ID: <469FD8A8.8070807@wichita.edu> Randy Coleburn wrote: > Tony: > > I'd like to better understand the implications of your change as I do > use LONGINT as an index in some applications. Do you have arrays that need 64-bit subscripts on a 32-bit machine? Allow me the common assumption that both integers and addresses have the native word size on most machines. In this case, most arrays that need 64-bit subscripts would exceed the virtual address space of the machine. Exceptions would require elements of size at most a byte, and overall sizes in excess of half the virtual address space. Even PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the virtual space before 32-bit subscripts ran out. All this seems pretty unlikely. I would favor keeping INTEGER as the type of open array subscripts and not allowing LONGINT to be a fixed array subscript type. It saves a whole lot of language complexity, and doesn't disallow much. If it really mattered, you could still use unsafe techniques for such memory-hogging arrays. This might be a reason to extend unsafe arithmetic on ADDRESS to accept LONGINT second operands. This is actually consistent with the rest of the operator generalizations. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From darko at darko.org Thu Jul 19 23:35:23 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 23:35:23 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FD59A.8020809@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FD59A.8020809@wichita.edu> Message-ID: <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> I agree with you and I strongly agree with Tony's approach to the implementation where the two integer types are not subtypes. The VAL usage would be a bit finicky given how often this would be done in practice, something more concise (like INT and LONG) would be better. On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote: > In my original 64-bit proposal, I made INTEGER # LONGINT, and also > the two > types have no subtype relation (which, I think is what Antony is > saying). > It avoids having a lot of things happen implicitly from other rules > in the > language. > > But then I added a separate rule that these two types and their > subranges > are mutually assignable, subject to the existing assignability > rules that > now apply to a type and its subranges. Namely the RHS value must be > in the > range of the of the LHS type, which sometimes has to be checked at > runtime. > > This allows assignment without explicit conversion, as well as many > other > things, for example, VALUE parameter passing, that require > assignability. > This is consistent with the existing rules for assignments involving > different subranges. > > For explicit conversions (which are probably needed somewhere anyway, > even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit > the existing language well. For consistency, it seems good to allow > ORD(LongIntArg), which is an alternative conversion in one direction. > It may seem unnecessary, but it's not as useless as ORD(IntegerArg), > which we already have. Actually, these extensions of VAL and ORD > fall out of the existing definitions, when LONGINT is an ordinal type. > > Darko wrote: >> I actually favour a implicit conversion, which for this >> particular case I think would be consistent with existing M3 >> behaviour. >> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >>> This is a good question. I would assume that conversion must be >>> explicit to fit with the M3 philosophy. It would make sense to >>> have a conversion operation that performs the appropriate range >>> check? Any ideas for a name for the operation. >>> >>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>> >>>> Have I missed something or is there no way to assign between >>>> INTEGER and LONGINT? Is there an explicit conversion function >>>> that I've overlooked? Would assignment be so bad here since >>>> there would be an implicit range check, much like when you >>>> assign between two overlapping subranges? In a sense these two >>>> types are integer subranges of an abstract integer type >>>> containing all integers. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From darko at darko.org Fri Jul 20 00:02:55 2007 From: darko at darko.org (Darko) Date: Fri, 20 Jul 2007 00:02:55 +0200 Subject: [M3devel] LONGINT In-Reply-To: <469FD8A8.8070807@wichita.edu> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> Message-ID: <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> I think in 64 bit land you get a variety of combinations and possibly the most common is a 32 bit address space with 64 bit integers, since applications seldom need to operate in the larger address space. But I would think it you wouldn't allocate an object bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would be more likely. The only situation where I can think of where this is an issue is using a long integer index in an array of integer proportions, you could handle this using arithmetic, also illustrates where you'd need an implicit conversion: CONST start = 2^63-500; end = 2^63-200; VAR a: ARRAY[0..start-end+1] OF CHAR; BEGIN FOR i := start TO end DO a[INT(i-start)] := 'x' END; Or you could rule that all arrays are of INTEGER size, but may have a LONGINT index. Open arrays would always be integers. This would probably be messy to implement and NUMBER would have a different base to FIRST and LAST. That doesn't sound very good. On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote: > > > Randy Coleburn wrote: >> Tony: >> I'd like to better understand the implications of your change as >> I do use LONGINT as an index in some applications. > > Do you have arrays that need 64-bit subscripts on a 32-bit machine? > > Allow me the common assumption that both integers and addresses have > the native word size on most machines. In this case, most arrays that > need 64-bit subscripts would exceed the virtual address space of the > machine. Exceptions would require elements of size at most a byte, > and overall sizes in excess of half the virtual address space. Even > PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the > virtual space before 32-bit subscripts ran out. All this seems pretty > unlikely. > > I would favor keeping INTEGER as the type of open array subscripts > and not allowing LONGINT to be a fixed array subscript type. It > saves a whole lot of language complexity, and doesn't disallow much. > > If it really mattered, you could still use unsafe techniques for > such memory-hogging arrays. This might be a reason to extend unsafe > arithmetic on ADDRESS to accept LONGINT second operands. This is > actually consistent with the rest of the operator generalizations. >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Jul 20 00:04:14 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 17:04:14 -0500 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: <469FDFDE.9020201@wichita.edu> Tony Hosking wrote: > On Jul 19, 2007, at 4:33 PM, Darko wrote: > >> I actually favour a implicit conversion, which for this particular >> case I think would be consistent with existing M3 behaviour. > > > There is no implicit conversion for floats. The danger with implicit > conversion for integers is that it would not be portable: you would get > different behavior on different machines for the same code. Better to > make the conversion explicit so that programmers are prepared for the > range check to fail. But is this argument any stronger for requiring explicit conversions for INTEGER/LONGINT assignments than for assigning to subranges? Many assignments in the language now, without any type conversion, admit the possibility of RT range errors. And these can be dependent on the size of INTEGER too. Consider: VAR V : [ 0 .. 65535 ] ; VAR I : CARDINAL ; ... V := I DIV 2 ; I think for portability, the principle that the static semantics should be the same for all sizes of INTEGER (and LONGINT too) is as much as we can hope for. Certainly, there are already countless ways the integer size can change the dynamic semantics of a program. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From darko at darko.org Thu Jul 19 20:41:08 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 20:41:08 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> This really is great stuff Tony, thanks for doing the hard yards. Will you be making a build of this available in your usual spot? I'd like to try this out for a while and look for creative ways to make it break (no offence intended) and get a feel for where it needs to be extended. In the spirit of the M3 founding fathers, I think we need some experience with this and then look at the simplest and smallest change we can do to support what is missing. Cheers, Darko. On 19/07/2007, at 5:31 PM, Tony Hosking wrote: > My LONGINT implementation addresses many of your concerns. The > LONGINT space is segregated from the INT space. I want to come up > with an implementation that also permits ordinals based on LONGINT > in addition to the current system of ordinals based on INTEGER. > This requires revisiting the language spec and pushing through the > implications. I'm going to look at that briefly before moving on > to fixing user-level threading for all targets. > > On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: > >> Hello everyone, >> >> I have read the various proposals for supporting integers of >> different >> bit sizes and am getting a little worried that they are running >> away from the traditional Modula-3 simplicity. As far as I know, >> there is very little in Modula-3 that depends on the actual size >> in bits of INTEGERs and CARDINALs. It doesn't seem to me to make >> much sense to introduce types like Int32.T and Int64.T and then >> make the definition Int32.T = INTEGER (on one platform) and Int64.T >> = INTEGER (on another platform). I'm wondering if it would instead >> be possible to introduce a new group of types in the sense that >> Modula-3 now has integer types and floating-point types, and call >> these types "fixed width" or "specified width" types. Conversions >> between these types and INTEGER or CARDINAL would have to be done >> using functions (operators) that are the analogs of FLOAT, ROUND, >> etc. Standard arithmetic operators would be overloaded just like >> they are today for integers and floating-point numbers. Am I just >> duplicating someone else's proposal here? Perhaps this proposal >> doesn't address everything one might want to do with these extended- >> size types? >> >> Maybe I am just dreaming about getting Modula-3 running on a >> DECsystem-20 with 36-bit integers...with pickles that are >> interchangeable >> with i386 pickles, of course. >> >> What do people want to do with these extended-size types anyhow? >> It seems good to me that INTEGER is the largest type that I can >> expect my processor to calculate efficiently with. I would use >> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible >> and write my code to be flexible about the BYTE/BITSIZE... but OK, >> I can see the rationale for hiding all this in the compiler (and >> inlining everything) in the few cases where I might want four- >> function >> arithmetic on (specifically) 64- or 128-bit integers. >> >> Mika >> >> Darko writes: >>> Actually I stated the wrong reason for that one, it's really an >>> argument against mixed integer assignment. >>> >>> And saying that it looks right from the C/C++ point of view is >>> pretty >>> damning... >>> >>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >>> >>>> Mail from unsubscribed address forwarded to the list... >>>> ---------------------------- Original Message >>>> ---------------------------- >>>> Subject: Re: A nonnative 64-bit language proposal >>>> From: hendrik at topoi.pooq.com >>>> Date: Wed, October 25, 2006 14:22 >>>> To: m3devel at elegosoft.com >>>> ------------------------------------------------------------------- >>>> --- >>>> ---- >>>> >>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>>> >>>>> For your example to compute as an integer even if that >>>>> overflows and >>>>> it wouldn't as a longint seems right from my C/C++ point of view. >>>> >>>> I've always thought C/C++ were badly wrong on this one, even >>>> from their own archaic low-level machine-oriented viewpoint. >>>> Most computers have integer multiply instructions that return a >>>> double-length product. >>>> >>>> -- hendrik >>>> >>>> > From darko at darko.org Fri Jul 20 04:49:08 2007 From: darko at darko.org (Darko) Date: Fri, 20 Jul 2007 04:49:08 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FD59A.8020809@wichita.edu> <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> Message-ID: <9A8114D3-DD14-459E-A423-DA1947A15235@darko.org> On the other side of the ledger, the fact that the following overflows is pretty unpleasant: CONST big = 2^32-1; VAR i: LONGINT; BEGIN i := big * big; On 19/07/2007, at 11:35 PM, Darko wrote: > I agree with you and I strongly agree with Tony's approach to the > implementation where the two integer types are not subtypes. > > The VAL usage would be a bit finicky given how often this would be > done in practice, something more concise (like INT and LONG) would > be better. > > > On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote: > >> In my original 64-bit proposal, I made INTEGER # LONGINT, and also >> the two >> types have no subtype relation (which, I think is what Antony is >> saying). >> It avoids having a lot of things happen implicitly from other >> rules in the >> language. >> >> But then I added a separate rule that these two types and their >> subranges >> are mutually assignable, subject to the existing assignability >> rules that >> now apply to a type and its subranges. Namely the RHS value must >> be in the >> range of the of the LHS type, which sometimes has to be checked at >> runtime. >> >> This allows assignment without explicit conversion, as well as >> many other >> things, for example, VALUE parameter passing, that require >> assignability. >> This is consistent with the existing rules for assignments involving >> different subranges. >> >> For explicit conversions (which are probably needed somewhere anyway, >> even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit >> the existing language well. For consistency, it seems good to allow >> ORD(LongIntArg), which is an alternative conversion in one direction. >> It may seem unnecessary, but it's not as useless as ORD(IntegerArg), >> which we already have. Actually, these extensions of VAL and ORD >> fall out of the existing definitions, when LONGINT is an ordinal >> type. >> >> Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >>> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >>>> This is a good question. I would assume that conversion must >>>> be explicit to fit with the M3 philosophy. It would make sense >>>> to have a conversion operation that performs the appropriate >>>> range check? Any ideas for a name for the operation. >>>> >>>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>>> >>>>> Have I missed something or is there no way to assign between >>>>> INTEGER and LONGINT? Is there an explicit conversion function >>>>> that I've overlooked? Would assignment be so bad here since >>>>> there would be an implicit range check, much like when you >>>>> assign between two overlapping subranges? In a sense these two >>>>> types are integer subranges of an abstract integer type >>>>> containing all integers. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > From mika at async.caltech.edu Fri Jul 20 09:16:09 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Jul 2007 00:16:09 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Thu, 19 Jul 2007 11:27:48 EDT." Message-ID: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> Hi again Tony, I am wondering, is it at all possible you might have to compile the new compiler with itself to get it to generate the proper code? I was at first able to get Juno to crash: *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/JunoRT.m3", line 698 *** but after recompiling a second time, it no longer seems to do that. By the way, I am somewhat suspicious that this Juno crash has something to do with threading: if you look closely, that part of Juno has to do with thread switching into and out of the Juno-machine...which is why I was happy to see it disappear (however it did that). I still have a threading crash in mentor. I run "Wheeler" to get this one... gdb /usr/local/cm3/bin/mentor GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .......................................... done (gdb) run Starting program: /usr/local/cm3/bin/mentor Reading symbols for shared libraries .++++++++++++++++++++.++++++++++++++++++ done *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675 *** Program exited with code 01. (gdb) where No stack. (gdb) cvs status ./m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3 =================================================================== File: ThreadPThread.m3 Status: Up-to-date Working revision: 1.34 Repository revision: 1.34 /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v Commit Identifier: GYzMl9TO92Eakoqs Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) [QT:~/cm3] mika% OS: 10.4 / ppc (My 10.3 machine is in for service at the moment.) Also the Bresenham demo just dies for me now, but that could of course be a bug in mentor. It was working great the other day.. not sure what happened there. I really don't think it's my old system that's corrupting the new images, but I am *never* 100% certain of that. I found a very weird behavior with the build system, actually. I found that the not-yet-installed compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in /usr/local/cm3/bin, but *only* if that is in the shell PATH. Is that a known/desired behavior? It causes the brand new compiler to use the old cm3.cfg, and it does so quietly without any warnings or messages whatsoever. Changing your PATH makes it stop do that and instead crash, prompting me to put the cm3.cfg I want in the right place... Mika P.S. I agree with you that 8000 threads is ample and good going for pthreads. Tony Hosking writes: >Mika, > >I have diagnosed and fixed the problems you were seeing with thread >pausing and alerts. mentor no longer exhibits the bug you reported >and diagnosed. Thanks! I am starting to feel much more confident >about the threads subsystem now that I am able to run mentor's >functionality without problems on my Darwin 10.4.10 system using >pthreads. There are still the capacity problems (number of pthreads >beyond 8000) on Darwin, but that is a system issue not a problem with >the pthreads implementation. For large numbers of threads the user- >level implementation still seems the way to go. I want to update >that to use getcontext/setcontext ASAP so that it will function again >on platforms that have implemented secure (encrypting) versions of >setjmp/longjmp that prevent stack hacks like those used to implement >the current user-level threads system. Thanks again for your help, >and please let me know of any further issues. > >-- Tony > >On Jul 17, 2007, at 3:31 AM, Mika Nystrom wrote: > >> Hi Tony, >> >> I have a friend with a 10.4.10 system, >> >> Darwin QT.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 >> 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh >> powerpc >> >> I used your instructions again, installing from the CVS head. You're >> right, things are different on this OS! The programs that were >> taking 100% cpu (mine as well as the ones in the distribution) on >> my 10.3 system are not doing that on the the 10.4 system. ktok >> still crashes, now sometimes with an illegal instruction, sometimes >> at line 2310, as before. >> >> After some fiddling, during which mentor worked far better than on >> 10.3, I was able to get mentor to---as it appears---deadlock. The >> Bresenham demo seems to deadlock mentor pretty reliably for me. >> Here's a traceback from hitting ctrl-C after mentor has gone >> catatonic: >> >> (gdb) where >> #0 0x9002c3c8 in semaphore_wait_signal_trap () >> #1 0x90030eac in pthread_cond_wait () >> #2 0x01d2d83c in ThreadPThread__InnerWait (M3_AYIbX3_m=0x2860540, >> M3_Bl0jv4_c=0x2a43b24, M3_BXP32l_self=0x2860014) at >> ThreadPThread.m3:212 >> #3 0x01d2dc6c in Thread__Wait (M3_AYIbX3_m=0x2860540, >> M3_Bl0jv4_c=0x2a43b24) at ThreadPThread.m3:251 >> #4 0x018991d8 in Trestle__AwaitDelete (M3_BFdKo9_v=0x2a0a9cc) at >> Trestle.m3:884 >> #5 0x0120b058 in ZeusPanel__Interact (M3_Bd56fi_title=0x36ace0, >> M3_DYb95R_path=0x2863f94) at ZeusPanel.m3:477 >> #6 0x0028af0c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:165 >> #7 0x01d16654 in RTLinker__RunMainBody (M3_DjPxE3_m=0x2b1428) at >> RTLinker.m3:399 >> #8 0x01d15418 in RTLinker__AddUnitI (M3_DjPxE3_m=0x2b1428) at >> RTLinker.m3:113 >> #9 0x01d15514 in RTLinker__AddUnit (M3_DjPxE5_b=0x28ae88) at >> RTLinker.m3:122 >> #10 0x00002a44 in main (argc=1, argv=0xbffffc98, envp=0xbffffca0) >> at _m3main.mc:4 >> >> My program that was having trouble with pickles now does the >> following. It is reading data out of a disk file that it has >> recently written using Pickle.Write. I'm afraid I can't give out >> the source code for this program, so I'll have to isolate a simpler >> case. Btw, this happens also with @M3nogc. No UNSAFE code of any >> kind involved here. Attempting to access the arguments of Text.Equal >> through gdb crashes gdb with a bus error. If someone has an idea >> (even a vague one) what might be the problem I could spend some >> time poking around the code... >> >> ((1)) FIXPersistentState.Init: initialized tbl backed by "states/ >> asdfw_25fwds.snt" >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 >> 0x900031c8 in strlen () >> (gdb) where >> #0 0x900031c8 in strlen () >> #1 0x01671c70 in Text8CString__GetInfo (M3_A8R5P5_t=0x1fb17f8, >> M3_BUgnwf_info=0xbfffe4bc) at Text8CString.m3:23 >> #2 0x0166dbd4 in Text__Equal (M3_Bd56fi_t=0x1fb17f8, >> M3_Bd56fi_u=0x1f9322c) at Text.m3:31 >> #3 0x003a8fd0 in FIXEngine__SanityCheckFields >> (M3_EdNxIG_t=0x1f953b0, M3_Ck0t2u_msg=0x1fb177c) at FIXEngine.m3:259 >> #4 0x003aad58 in FIXEngine__InitSession (M3_EdNxIG_t=0x1f953b0, >> M3_CVvbAZ_session=0x1f93290) at FIXEngine.m3:450 >> #5 0x003a9ad4 in FIXEngine__Init (M3_EdNxIG_t=0x1f953b0, >> M3_Cbj6ab_conn=0x1f95454, M3_CqtnCQ_mode=0 '\0', >> M3_Cwb5VA_heartBtInt=, M3_CVvbAZ_session=0x1f93290, >> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', >> M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=> 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=, >> M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Fri Jul 20 17:42:27 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 11:42:27 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> References: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> Message-ID: <066BF1FB-7815-4761-A04F-ED68A75564A5@cs.purdue.edu> 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=, M3_CVvbAZ_session=0x1f93290, >>> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', >>> M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=>> 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=, >>> M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Fri Jul 20 22:47:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 16:47:45 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FDFDE.9020201@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FDFDE.9020201@wichita.edu> Message-ID: <05CD4EBC-E1C6-4BB7-919C-8032B5265609@cs.purdue.edu> I think I am coming around to Rodney's position. We should consider INTEGER and LONGINT assignable under the current rules for subranges. Thus, INTEGER := LONGINT will cause a range check (and underlying conversion of the integer value from BITSIZE(LONGINT) to BITSIZE(INTEGER)), whereas LONGINT := INTEGER will need not check (though the conversion will be necessary to extend sign as expected). I believe this functionality can easily be implemented in the current compiler. Also, I am willing to allow indexing of arrays using LONGINT-based ordinals for the index type. The usual restrictions on array size will obtain, and zero-based array indexes will be computed into integer offsets. Thus, for an array indexed [minL..maxL] where minL and maxL have base type LONGINT, the offset will be computed as: index - minL and converted to an INTEGER value to index the array. Because of the sizing restriction, index - minL must be expressible as an INTEGER. Here are my revised notes: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longint.txt URL: -------------- next part -------------- On Jul 19, 2007, at 6:04 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> On Jul 19, 2007, at 4:33 PM, Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >> There is no implicit conversion for floats. The danger with >> implicit conversion for integers is that it would not be >> portable: you would get different behavior on different machines >> for the same code. Better to make the conversion explicit so >> that programmers are prepared for the range check to fail. > > But is this argument any stronger for requiring explicit conversions > for INTEGER/LONGINT assignments than for assigning to subranges? > Many assignments in the language now, without any type conversion, > admit the possibility of RT range errors. And these can be dependent > on the size of INTEGER too. Consider: > > VAR V : [ 0 .. 65535 ] ; > VAR I : CARDINAL ; > ... > V := I DIV 2 ; > > I think for portability, the principle that the static semantics > should be > the same for all sizes of INTEGER (and LONGINT too) is as much as > we can > hope for. Certainly, there are already countless ways the integer > size can > change the dynamic semantics of a program. > > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From mika at async.caltech.edu Sun Jul 22 14:12:07 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Jul 2007 05:12:07 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Fri, 20 Jul 2007 11:42:27 EDT." <066BF1FB-7815-4761-A04F-ED68A75564A5@cs.purdue.edu> Message-ID: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Tony Hosking writes: ... >> 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 *obsessively* clean my directories between builds! I have double- and triple-checked that nothing in the source tree is left in object form after doing do-cm3-std.sh realclean do-cm3-core.sh realclean Yet, this happens. My best guess is that somehow, old objects (from /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. Surely that's not supposed to happen? Why does it happen to me and apparently not to you? I follow your directions exactly and always start from an absolutely clean system (on Mac I don't even have PM3 installed, so there's no Modula-3 at all before I start following the instructions). >> I still have a threading crash in mentor. I run "Wheeler" to get this >> one... >> ... >> >> *** >> *** 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. Debugging this a bit further, I think I'm just running out of stack space. You are saying that this call can fail because of too small a requested stack space, too? It might be nice to have some sort of error message here instead of just an assert failure... How big is your stack limit on your mac? On mine it's 64 megabytes, and when I added some printing: RTIO.PutText("Upthread.attr_getstacksize returned bytes="); RTIO.PutInt(bytes); RTIO.PutText(" defaultStackSize="); RTIO.PutInt(defaultStackSize); RTIO.PutChar('\n'); bytes := MAX(bytes, size * ADRSIZE(Word.T)); WITH r = Upthread.attr_setstacksize(attr, bytes) DO IF r # 0 THEN RTIO.PutText("Upthread.attr_setstacksize failed, size="); ELSE RTIO.PutText("Upthread.attr_setstacksize succeeded, size="); END; RTIO.PutInt(size); RTIO.PutText(" bytes="); RTIO.PutInt(bytes); RTIO.PutChar('\n'); <*ASSERT r=0*> END; RTIO.Flush(); I found the following: (running Wheeler) ... lots of times ... Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 Upthread.attr_getstacksize returned bytes=524288 defaultStackSize=79632 Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 Upthread.attr_getstacksize returned bytes=524288 defaultStackSize=79632 Upthread.attr_setstacksize failed, size=637056 bytes=2548224 *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 *** Program exited with code 01. It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize for another 64 kilowords , and WheelerCompressObliqView.m3 requests 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads and I just run out of stack space. (I am assuming that pthreads allocates stacks in the 'stack' segment of the process...) Attempting to fix the bug in mentor makes it run out of stack space, looks like it's some recursive descent parser... Maybe this demo just won't run on my computer. >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 was able to get it to run again. And deadlock again. And run again... it's definitely something intermittent. I think it happens right when it attempts to start the threads, not afterwards. And when you ctrl-C it, all you get is that it's stopped in Trestle__AwaitDelete (I already sent this one). > >> 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. > Here's what I'm doing... I install cm3-5.4.0 from the elegosoft site using that package's cminstall. This installs a cm3.cfg. Then I follow your directions for bootstrapping from the CVS head. At some point, those directions say to switch from using the original compiler to the newly compiled compiler. Now, when you switch to the newly compiled compiler, the only cm3.cfg in the system is the one from the bootstrappING compiler, that is, the 5.4.0 release cm3.cfg. What happens is the following: 1. If my shell PATH includes the path to the old cm3, the new compiler (silently) finds the old cm3.cfg and uses it. 2. If my shell PATH does not include the path to the old cm3, the new compiler does not find the old cm3.cfg. This behavior will easily trip someone up who's trying to bootstrap cm3, because I don't think any of the scripts (or bootstrapping directions) do anything whatever to make sure that the new compiler gets a new cm3.cfg. What I've taken to doing is taking cm3 out of my PATH permanently so that I always have to type the full path. That way I can't get a compiler-cfg mismatch, because the new compiler will refuse to work until I have provided it with a new cm3.cfg. I've been doing this for the last several bootstraps. Mika From hosking at cs.purdue.edu Sun Jul 22 17:16:10 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 22 Jul 2007 11:16:10 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> References: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: Hi Mika, Thanks for all of your useful feedback. My replies below... On Jul 22, 2007, at 8:12 AM, Mika Nystrom wrote: > > Tony Hosking writes: > ... >>> 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 *obsessively* clean my directories between builds! I have double- > and triple-checked that nothing in the source tree is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, old objects (from > /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. > Surely that's not supposed to happen? Why does it happen to me and > apparently not to you? I follow your directions exactly and always > start from an absolutely clean system (on Mac I don't even have PM3 > installed, so there's no Modula-3 at all before I start following > the instructions). I'm not trying to imply that you are doing anything wrong -- just wanting to make sure that we isolate the problem carefully in order to diagnose it. As I have mentioned in the past, I hand-build my bootstrap compilers, avoiding using the scripts, since the order of package builds can vary depending on which parts of the runtime and compiler subsystems have been changed. I only use the do-cm3-std.sh script once I am sure I have a functional compiler. Have you managed to reproduce the error from before? > > >>> I still have a threading crash in mentor. I run "Wheeler" to get >>> this >>> one... >>> > ... >>> >>> *** >>> *** 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. > > Debugging this a bit further, I think I'm just running out of stack > space. You are saying that this call can fail because of too small > a requested stack space, too? It might be nice to have some sort > of error message here instead of just an assert failure... Yes, that's why I think it may be better to try pthread_attr_setstacksize without checking the return value. Better to ignore a bad sized closure's request for a particular size than to crash and burn. > > How big is your stack limit on your mac? On mine it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize succeeded, > size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize > for another 64 kilowords , and WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads > and I just run out of stack space. (I am assuming that pthreads > allocates stacks in the 'stack' segment of the process...) Yes, that is probably the case. > > Attempting to fix the bug in mentor makes it run out of stack space, > looks like it's some recursive descent parser... Maybe this demo > just won't run on my computer. This is troubling. Perhaps we should more explicitly allocate stacks from the heap so as to avoid this issue. I can look into this. > >> 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 was able to get it to run again. And deadlock again. And run > again... it's definitely something intermittent. I think it happens > right when it attempts to start the threads, not afterwards. > > And when you ctrl-C it, all you get is that it's stopped > in Trestle__AwaitDelete (I already sent this one). Hmm. More food for thought. >>> 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. >> > > Here's what I'm doing... > > I install cm3-5.4.0 from the elegosoft site using that package's > cminstall. This installs a cm3.cfg. > > Then I follow your directions for bootstrapping from the CVS head. > At some point, those directions say to switch from using the original > compiler to the newly compiled compiler. > > Now, when you switch to the newly compiled compiler, the only cm3.cfg > in the system is the one from the bootstrappING compiler, that is, the > 5.4.0 release cm3.cfg. What happens is the following: > > 1. If my shell PATH includes the path to the old cm3, the new compiler > (silently) finds the old cm3.cfg and uses it. > > 2. If my shell PATH does not include the path to the old cm3, the new > compiler does not find the old cm3.cfg. > > This behavior will easily trip someone up who's trying to bootstrap > cm3, because I don't think any of the scripts (or bootstrapping > directions) do anything whatever to make sure that the new compiler > gets a new cm3.cfg. What I've taken to doing is taking cm3 out of > my PATH permanently so that I always have to type the full path. > That way I can't get a compiler-cfg mismatch, because the new compiler > will refuse to work until I have provided it with a new cm3.cfg. > I've been doing this for the last several bootstraps. Yes, I think this is a problem. I have never used the CM3 install scripts, since I am in bootstrapping mode almost all the time as part of the development cycle, so I am always using the same cm3.cfg. I think your strategy is a good one for bootstrapping with a cminstall system present. > > > Mika From dabenavidesd at yahoo.es Sun Jul 22 21:31:42 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Jul 2007 21:31:42 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: <487036.69680.qm@web27110.mail.ukl.yahoo.com> Hi: What I have saw of the two step boostrapping process is that cm3 executable looks in its own directory for cm3.cfg, so I have made a copy from /usr/local/cm3/bin to /usr/local/cm3/pkg/cm3/LINUXLIBC6 Another thing is that do-cm3-std.sh realclean, doesnt clean some m3core parts, some yes. Thanks --- Mika Nystrom wrote: > > Tony Hosking writes: > ... > >> 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 *obsessively* clean my directories between builds! > I have double- > and triple-checked that nothing in the source tree > is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, > old objects (from > /usr/local/cm3/pkg?) are "leaking" through the > bootstrapping process. > Surely that's not supposed to happen? Why does it > happen to me and > apparently not to you? I follow your directions > exactly and always > start from an absolutely clean system (on Mac I > don't even have PM3 > installed, so there's no Modula-3 at all before I > start following > the instructions). > > > >> I still have a threading crash in mentor. I run > "Wheeler" to get this > >> one... > >> > ... > >> > >> *** > >> *** 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. > > Debugging this a bit further, I think I'm just > running out of stack > space. You are saying that this call can fail > because of too small > a requested stack space, too? It might be nice to > have some sort > of error message here instead of just an assert > failure... > > How big is your stack limit on your mac? On mine > it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize > returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, > bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize > failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize > succeeded, size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 > bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 > bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 > bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls > IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls > IncDefaultStackSize > for another 64 kilowords , and > WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of > those threads > and I just run out of stack space. (I am assuming > that pthreads > allocates stacks in the 'stack' segment of the > process...) > > Attempting to fix the bug in mentor makes it run out > of stack space, > looks like it's some recursive descent parser... > Maybe this demo > just won't run on my computer. > > >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 was able to get it to run again. And deadlock > again. And run > again... it's definitely something intermittent. I > think it happens > right when it attempts to start the threads, not > afterwards. > > And when you ctrl-C it, all you get is that it's > stopped > in Trestle__AwaitDelete (I already sent this one). > > > > >> 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, > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Mon Jul 23 09:29:41 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Jul 2007 09:29:41 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <487036.69680.qm@web27110.mail.ukl.yahoo.com> Message-ID: <412757.94770.qm@web27109.mail.ukl.yahoo.com> Hi, Actually the existing directories on m3-sys after execution of scripts/do-cm3-std.sh buildship: m3linker m3front cm3 On the These packages are not listed when that script inits I guess these packages are not necessary when boostrapping cm3 without steps. Executing scripts/do-cm3-core.sh realclean does that cleans. Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > What I have saw of the two step boostrapping process > is that cm3 executable looks in its own directory > for > cm3.cfg, so I have made a copy from > /usr/local/cm3/bin > to /usr/local/cm3/pkg/cm3/LINUXLIBC6 > > Another thing is that do-cm3-std.sh realclean, > doesnt > clean some m3core parts, some yes. > > > Thanks > > --- Mika Nystrom wrote: > > > > > Tony Hosking writes: > > ... > > >> 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 *obsessively* clean my directories between > builds! > > I have double- > > and triple-checked that nothing in the source tree > > is left in object > > form after doing > > > > do-cm3-std.sh realclean > > do-cm3-core.sh realclean > > > > Yet, this happens. My best guess is that somehow, > > old objects (from > > /usr/local/cm3/pkg?) are "leaking" through the > > bootstrapping process. > > Surely that's not supposed to happen? Why does it > > happen to me and > > apparently not to you? I follow your directions > > exactly and always > > start from an absolutely clean system (on Mac I > > don't even have PM3 > > installed, so there's no Modula-3 at all before I > > start following > > the instructions). > > > > > > >> I still have a threading crash in mentor. I > run > > "Wheeler" to get this > > >> one... > > >> > > ... > > >> > > >> *** > > >> *** 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. > > > > Debugging this a bit further, I think I'm just > > running out of stack > > space. You are saying that this call can fail > > because of too small > > a requested stack space, too? It might be nice to > > have some sort > > of error message here instead of just an assert > > failure... > > > > How big is your stack limit on your mac? On mine > > it's 64 megabytes, > > and when I added some printing: > > > > RTIO.PutText("Upthread.attr_getstacksize > > returned bytes="); > > RTIO.PutInt(bytes); > > RTIO.PutText(" defaultStackSize="); > > RTIO.PutInt(defaultStackSize); > > RTIO.PutChar('\n'); > > > > bytes := MAX(bytes, size * > ADRSIZE(Word.T)); > > WITH r = Upthread.attr_setstacksize(attr, > > bytes) DO > > IF r # 0 THEN > > > RTIO.PutText("Upthread.attr_setstacksize > > failed, size="); > > ELSE > > > RTIO.PutText("Upthread.attr_setstacksize > > succeeded, size="); > > END; > > RTIO.PutInt(size); > > RTIO.PutText(" bytes="); > > RTIO.PutInt(bytes); > > RTIO.PutChar('\n'); > > <*ASSERT r=0*> > > END; > > RTIO.Flush(); > > > > I found the following: > > > > (running Wheeler) > > > > ... lots of times ... > > Upthread.attr_setstacksize succeeded, size=79632 > > bytes=524288 > > Upthread.attr_getstacksize returned bytes=524288 > > defaultStackSize=79632 > > Upthread.attr_setstacksize succeeded, size=79632 > > bytes=524288 > > Upthread.attr_getstacksize returned bytes=524288 > > defaultStackSize=79632 > > Upthread.attr_setstacksize failed, size=637056 > > bytes=2548224 > > > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file > > "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > > *** > > > > > > Program exited with code 01. > > > > It's really a bug in mentor. Zeus.m3:499 calls > > IncDefaultStackSize > > to request another 10 kilowords, Obliq.m3:32 calls > > IncDefaultStackSize > > for another 64 kilowords , and > > WheelerCompressObliqView.m3 requests > > 8*GetDefaultStackSize in a SizedClosure. A bunch > of > > those threads > > and I just run out of stack space. (I am assuming > > that pthreads > > allocates stacks in the 'stack' segment of the > > process...) > > > > Attempting to fix the bug in mentor makes it run > out > > of stack space, > > looks like it's some recursive descent parser... > > Maybe this demo > > just won't run on my computer. > > > > >Weird, I was running Bresenham just fine > yesterday > > after the fix I > > >checked in. Sounds like you may have some stale > > object files lying > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From wagner at elegosoft.com Mon Jul 23 12:55:22 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Jul 2007 12:55:22 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <412757.94770.qm@web27109.mail.ukl.yahoo.com> References: <412757.94770.qm@web27109.mail.ukl.yahoo.com> Message-ID: <37913.194.138.127.36.1185188122.squirrel@mail.elegosoft.com> do-cm3-std.sh is the script that builds the complete set of usable M3 application packages after an initial CM3 installation. It has no connection to compiler bootstrapping at all. do-cm3-core.sh is a script that can be used to build a basic system without any demos or large applications, but including the compiler itself. It can usually not be used for bootstrapping the compiler either (at least on its own, as changes in supported platforms or other core units may require more elaborate build and ship schemes). The scripts were intended for the M3 end user and not for the rather special situation of language and runtime development of CM3 itself. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Mon Jul 23 15:43:37 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Jul 2007 15:43:37 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <37913.194.138.127.36.1185188122.squirrel@mail.elegosoft.com> Message-ID: <502092.9992.qm@web27110.mail.ukl.yahoo.com> Hi, actually I meant when doing the two step bootstrapping process the existing directories (TARGET) on m3-sys after execution of scripts/do-cm3-std.sh realclean are: m3linker m3front cm3 These packages are not listed when that script inits I guess these packages are not necessary when boostrapping cm3 without steps. Executing scripts/do-cm3-core.sh realclean does that cleans. Thanks --- Olaf Wagner wrote: > do-cm3-std.sh is the script that builds the complete > set of usable > M3 application packages after an initial CM3 > installation. It has > no connection to compiler bootstrapping at all. > > do-cm3-core.sh is a script that can be used to build > a basic system > without any demos or large applications, but > including the compiler > itself. It can usually not be used for > bootstrapping the compiler > either (at least on its own, as changes in > supported platforms or > other core units may require more elaborate build > and ship schemes). > > The scripts were intended for the M3 end user and > not for the rather > special situation of language and runtime > development of CM3 itself. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 > | USt-IdNr: DE163214194 > > ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From mika at async.caltech.edu Tue Jul 24 15:54:28 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 24 Jul 2007 06:54:28 -0700 Subject: [M3devel] Question about TEXTs under CM3 Message-ID: <200707241354.l6ODsSh6032994@camembert.async.caltech.edu> Hello everyone, Here's a random question that hopefully someone can answer... Is it true that certain TEXTs can't be Pickled under CM3? Unless there's some magic I don't understand going on, I am thinking that would be the implication of: UNSAFE INTERFACE Text8CString; ... TYPE T <: Public; Public = TEXT OBJECT str: Ctypes.char_star; END; (* The array contains the characters of the text followed by a '\000'. *) ... I hope someone can set me straight and tell me that no, the situation isn't as dire as that---some clever thing somewhere makes it possible to Pickle all objects of type TEXT... Mika From mika at async.caltech.edu Thu Jul 26 14:40:29 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Jul 2007 05:40:29 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Tue, 24 Jul 2007 06:54:28 PDT." <200707241354.l6ODsSh6032994@camembert.async.caltech.edu> Message-ID: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Ok, I am about to answer my own email. Here's a little program I wrote: MODULE Main; IMPORT Pickle, IO, Params, TextWr, TextRd; VAR wr := NEW(TextWr.T).init(); toPickle := "pickle this"; BEGIN IF Params.Count > 1 THEN toPickle := Params.Get(1) END; Pickle.Write(wr,toPickle); IO.Put("pickled \""&toPickle&"\"\n"); IO.Put("read back \""& Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) &"\"\n"); END Main. === On FreeBSD4 with my ancient, creaky PM3: (64)trs80:~/ptest/src>../FreeBSD4/pickleit pickled "pickle this" read back "pickle this" (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that pickled "pickle that" read back "pickle that" === On PPC_DARWIN with the latest CM3: [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickled "pickle this" read back "pickle this" [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that pickled "pickle that" *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** Abort === On FreeBSD4 with the latest CM3: (73)rover:~/ptest/src>../FreeBSD4/pickleit pickled "pickle this" read back "pickle this" (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that pickled "pickle that" *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** Abort ============ Diagnosis: The code I mentioned in a previous email declares a Text8CString.T to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere in the system, Ctypes.char_star is specifically declared to be an "UNTRACED REF Ctypes.char". According to the specification of Pickle, an UNTRACED REF is pickled as NIL. Generally speaking, you don't see many Text8CString.Ts in the system. This one comes in via Params.Get, which in turn calls RTArgs.GetArg, which in turn calls M3toC.StoT. StoT is generally not something you want to call, but it's supposed to be OK here because you're just passing around argv, which won't change. Generally speaking, it ought to be OK to use to convert C strings whose addresses aren't going to change during the lifetime of the program. I think it is *totally unacceptable* that Params.Get returns a "poisoned" TEXT. There is absolutely nothing in any of the interfaces that warns of this fact, and it is surprising to say the least. There is also no simple way of "copying" TEXTs, as it shouldn't ever be required! Finally, there's no way of checking whether a TEXT is a Text8CString.T without importing Text8CString, which is an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! What does baffle me a bit is that the code works on the old PM3. It uses the old TextF, which declares TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; The old (from PM3, I think it's 1.1.15) M3toC has: PROCEDURE StoT (s: Ctypes.char_star): TEXT = VAR t := NEW (M3TextWithHeader); BEGIN t.header.typecode := RT0.TextTypecode; t.body.chars := LOOPHOLE (s, ADDRESS); t.body.length := 1 + Cstring.strlen (s); RETURN LOOPHOLE (ADR (t.body), TEXT); END StoT; I'm not entirely sure why the old code works---why isn't the M3TextWithHeader garbage-collected? The pickler doesn't seem to know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. In fact the pickler doesn't seem to know anything about TEXTs at all. I see several possible ways of solving the problem. One is to permit M3toC.StoT to remain broken (since M3toC is an UNSAFE interface, there's no "legal" reason not to do that) and make sure Params.Get (and everything else that could remotely be called "standard") doesn't use M3toC.StoT---oh and to leave some very prominent warning signs, both in M3toC and Text8CString that "here be demons". Another is to revert to the SRC method of LOOPHOLEing the C strings. I never liked the CM3 TEXTs, and I like them even less now; I disliked them from the start because they broke pickle compatibility with SRC M3, and now I find that they aren't even compatible with themselves. Modula-3's strengths have always been its utter simplicity and bullet-proof reliability. This stuff, where some objects are more "serializable" than others, reminds me of Java! Does anyone have an opinion as to how this problem ought to be solved? Mika Mika Nystrom writes: >Hello everyone, > >Here's a random question that hopefully someone can answer... > >Is it true that certain TEXTs can't be Pickled under CM3? > >Unless there's some magic I don't understand going on, I am thinking >that would be the implication of: > >UNSAFE INTERFACE Text8CString; >... >TYPE > T <: Public; > Public = TEXT OBJECT > str: Ctypes.char_star; > END; > (* The array contains the characters of the text followed by a '\000'. *) >... > >I hope someone can set me straight and tell me that no, the situation >isn't as dire as that---some clever thing somewhere makes it possible >to Pickle all objects of type TEXT... > > Mika From hosking at cs.purdue.edu Thu Jul 26 15:47:46 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 09:47:46 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Message-ID: Looks like we need to fix M3toC.StoT so that it works the same as old PM3. The old code works because it constructs a text *in* the heap as an ARRAY OF CHAR, that just happens to have its payload (the array contents) outside the heap. (Arrays in M3 contain a reference to their data). We can play the same trick for Text8CString and get things to work properly for you. I will make this fix and check it in. On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: > Ok, I am about to answer my own email. Here's a little program I > wrote: > > MODULE Main; > IMPORT Pickle, IO, Params, TextWr, TextRd; > > VAR wr := NEW(TextWr.T).init(); > toPickle := "pickle this"; > BEGIN > IF Params.Count > 1 THEN toPickle := Params.Get(1) END; > > Pickle.Write(wr,toPickle); > > IO.Put("pickled \""&toPickle&"\"\n"); > IO.Put("read back \""& > Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) > &"\"\n"); > END Main. > > === On FreeBSD4 with my ancient, creaky PM3: > > (64)trs80:~/ptest/src>../FreeBSD4/pickleit > pickled "pickle this" > read back "pickle this" > (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that > pickled "pickle that" > read back "pickle that" > > === On PPC_DARWIN with the latest CM3: > > [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit > pickled "pickle this" > read back "pickle this" > [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that > pickled "pickle that" > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** > > Abort > > === On FreeBSD4 with the latest CM3: > > (73)rover:~/ptest/src>../FreeBSD4/pickleit > pickled "pickle this" > read back "pickle this" > (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that > pickled "pickle that" > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** > > Abort > > ============ > > Diagnosis: > > The code I mentioned in a previous email declares a Text8CString.T > to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere > in the system, Ctypes.char_star is specifically declared to be an > "UNTRACED REF Ctypes.char". According to the specification of > Pickle, an UNTRACED REF is pickled as NIL. > > Generally speaking, you don't see many Text8CString.Ts in the system. > This one comes in via Params.Get, which in turn calls RTArgs.GetArg, > which in turn calls M3toC.StoT. > > StoT is generally not something you want to call, but it's supposed > to be OK here because you're just passing around argv, which won't > change. Generally speaking, it ought to be OK to use to convert > C strings whose addresses aren't going to change during the lifetime > of the program. > > I think it is *totally unacceptable* that Params.Get returns a > "poisoned" TEXT. There is absolutely nothing in any of the interfaces > that warns of this fact, and it is surprising to say the least. > There is also no simple way of "copying" TEXTs, as it shouldn't > ever be required! Finally, there's no way of checking whether a > TEXT is a Text8CString.T without importing Text8CString, which is > an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! > > What does baffle me a bit is that the code works on the old PM3. > It uses the old TextF, which declares > > TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; > > The old (from PM3, I think it's 1.1.15) M3toC has: > > PROCEDURE StoT (s: Ctypes.char_star): TEXT = > VAR t := NEW (M3TextWithHeader); > BEGIN > t.header.typecode := RT0.TextTypecode; > t.body.chars := LOOPHOLE (s, ADDRESS); > t.body.length := 1 + Cstring.strlen (s); > RETURN LOOPHOLE (ADR (t.body), TEXT); > END StoT; > > I'm not entirely sure why the old code works---why isn't the > M3TextWithHeader garbage-collected? The pickler doesn't seem to > know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. > In fact the pickler doesn't seem to know anything about TEXTs > at all. > > I see several possible ways of solving the problem. One is to > permit M3toC.StoT to remain broken (since M3toC is an UNSAFE > interface, there's no "legal" reason not to do that) and make sure > Params.Get (and everything else that could remotely be called > "standard") doesn't use M3toC.StoT---oh and to leave some very > prominent warning signs, both in M3toC and Text8CString that "here > be demons". Another is to revert to the SRC method of LOOPHOLEing > the C strings. I never liked the CM3 TEXTs, and I like them even > less now; I disliked them from the start because they broke pickle > compatibility with SRC M3, and now I find that they aren't even > compatible with themselves. > > Modula-3's strengths have always been its utter simplicity > and bullet-proof reliability. This stuff, where some objects are > more "serializable" than others, reminds me of Java! > > Does anyone have an opinion as to how this problem ought to be > solved? > > Mika > > Mika Nystrom writes: >> Hello everyone, >> >> Here's a random question that hopefully someone can answer... >> >> Is it true that certain TEXTs can't be Pickled under CM3? >> >> Unless there's some magic I don't understand going on, I am thinking >> that would be the implication of: >> >> UNSAFE INTERFACE Text8CString; >> ... >> TYPE >> T <: Public; >> Public = TEXT OBJECT >> str: Ctypes.char_star; >> END; >> (* The array contains the characters of the text followed by a >> '\000'. *) >> ... >> >> I hope someone can set me straight and tell me that no, the situation >> isn't as dire as that---some clever thing somewhere makes it possible >> to Pickle all objects of type TEXT... >> >> Mika From mika at async.caltech.edu Thu Jul 26 16:04:07 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Jul 2007 07:04:07 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Thu, 26 Jul 2007 09:47:46 EDT." Message-ID: <200707261404.l6QE47LU009706@camembert.async.caltech.edu> Tony Hosking writes: >Looks like we need to fix M3toC.StoT so that it works the same as old >PM3. The old code works because it constructs a text *in* the heap >as an ARRAY OF CHAR, that just happens to have its payload (the array >contents) outside the heap. (Arrays in M3 contain a reference to >their data). We can play the same trick for Text8CString and get >things to work properly for you. I will make this fix and check it in. > > >On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: ... >> Does anyone have an opinion as to how this problem ought to be >> solved? >> ... that's more than an opinion, but I'll happily accept it! :-) Mika From hosking at cs.purdue.edu Thu Jul 26 17:26:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 11:26:31 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Message-ID: <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> On closer inspection, it is even messier than that. In the old PM3 the text that is constructed is allocated in UNTRACED storage (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be GC'd, and looks (to the GC) like an (old-style) text literal allocated outside the heap. It is harder for us to fake up a text literal like this with the new TEXT setup since we'd need to allocate, copy, and loophole something that looks like a text literal (an object) in the untraced heap. The best alternative is to fix the pickler with a special that handles Text8Cstrings. I think this is the cleanest approach. Mika, please try the following program, which adds a special for Text8CString. I will put this code into the builtin specials for pickles. On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: > Looks like we need to fix M3toC.StoT so that it works the same as > old PM3. The old code works because it constructs a text *in* the > heap as an ARRAY OF CHAR, that just happens to have its payload > (the array contents) outside the heap. (Arrays in M3 contain a > reference to their data). We can play the same trick for > Text8CString and get things to work properly for you. I will make > this fix and check it in. > > > On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: > >> Ok, I am about to answer my own email. Here's a little program I >> wrote: >> >> MODULE Main; >> IMPORT Pickle, IO, Params, TextWr, TextRd; >> >> VAR wr := NEW(TextWr.T).init(); >> toPickle := "pickle this"; >> BEGIN >> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >> >> Pickle.Write(wr,toPickle); >> >> IO.Put("pickled \""&toPickle&"\"\n"); >> IO.Put("read back \""& >> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >> &"\"\n"); >> END Main. >> >> === On FreeBSD4 with my ancient, creaky PM3: >> >> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >> pickled "pickle this" >> read back "pickle this" >> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >> pickled "pickle that" >> read back "pickle that" >> >> === On PPC_DARWIN with the latest CM3: >> >> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >> pickled "pickle this" >> read back "pickle this" >> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >> pickled "pickle that" >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** >> >> Abort >> >> === On FreeBSD4 with the latest CM3: >> >> (73)rover:~/ptest/src>../FreeBSD4/pickleit >> pickled "pickle this" >> read back "pickle this" >> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >> pickled "pickle that" >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** >> >> Abort >> >> ============ >> >> Diagnosis: >> >> The code I mentioned in a previous email declares a Text8CString.T >> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >> in the system, Ctypes.char_star is specifically declared to be an >> "UNTRACED REF Ctypes.char". According to the specification of >> Pickle, an UNTRACED REF is pickled as NIL. >> >> Generally speaking, you don't see many Text8CString.Ts in the system. >> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >> which in turn calls M3toC.StoT. >> >> StoT is generally not something you want to call, but it's supposed >> to be OK here because you're just passing around argv, which won't >> change. Generally speaking, it ought to be OK to use to convert >> C strings whose addresses aren't going to change during the lifetime >> of the program. >> >> I think it is *totally unacceptable* that Params.Get returns a >> "poisoned" TEXT. There is absolutely nothing in any of the >> interfaces >> that warns of this fact, and it is surprising to say the least. >> There is also no simple way of "copying" TEXTs, as it shouldn't >> ever be required! Finally, there's no way of checking whether a >> TEXT is a Text8CString.T without importing Text8CString, which is >> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >> >> What does baffle me a bit is that the code works on the old PM3. >> It uses the old TextF, which declares >> >> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >> >> The old (from PM3, I think it's 1.1.15) M3toC has: >> >> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >> VAR t := NEW (M3TextWithHeader); >> BEGIN >> t.header.typecode := RT0.TextTypecode; >> t.body.chars := LOOPHOLE (s, ADDRESS); >> t.body.length := 1 + Cstring.strlen (s); >> RETURN LOOPHOLE (ADR (t.body), TEXT); >> END StoT; >> >> I'm not entirely sure why the old code works---why isn't the >> M3TextWithHeader garbage-collected? The pickler doesn't seem to >> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >> In fact the pickler doesn't seem to know anything about TEXTs >> at all. >> >> I see several possible ways of solving the problem. One is to >> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >> interface, there's no "legal" reason not to do that) and make sure >> Params.Get (and everything else that could remotely be called >> "standard") doesn't use M3toC.StoT---oh and to leave some very >> prominent warning signs, both in M3toC and Text8CString that "here >> be demons". Another is to revert to the SRC method of LOOPHOLEing >> the C strings. I never liked the CM3 TEXTs, and I like them even >> less now; I disliked them from the start because they broke pickle >> compatibility with SRC M3, and now I find that they aren't even >> compatible with themselves. >> >> Modula-3's strengths have always been its utter simplicity >> and bullet-proof reliability. This stuff, where some objects are >> more "serializable" than others, reminds me of Java! >> >> Does anyone have an opinion as to how this problem ought to be >> solved? >> >> Mika >> >> Mika Nystrom writes: >>> Hello everyone, >>> >>> Here's a random question that hopefully someone can answer... >>> >>> Is it true that certain TEXTs can't be Pickled under CM3? >>> >>> Unless there's some magic I don't understand going on, I am thinking >>> that would be the implication of: >>> >>> UNSAFE INTERFACE Text8CString; >>> ... >>> TYPE >>> T <: Public; >>> Public = TEXT OBJECT >>> str: Ctypes.char_star; >>> END; >>> (* The array contains the characters of the text followed by a >>> '\000'. *) >>> ... >>> >>> I hope someone can set me straight and tell me that no, the >>> situation >>> isn't as dire as that---some clever thing somewhere makes it >>> possible >>> to Pickle all objects of type TEXT... >>> >>> Mika From hosking at cs.purdue.edu Thu Jul 26 18:02:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 12:02:19 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> Message-ID: I'm about to check in the fix. I have tested this with your example program and things work fine. On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: > On closer inspection, it is even messier than that. In the old PM3 > the text that is constructed is allocated in UNTRACED storage > (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be > GC'd, and looks (to the GC) like an (old-style) text literal > allocated outside the heap. It is harder for us to fake up a text > literal like this with the new TEXT setup since we'd need to > allocate, copy, and loophole something that looks like a text > literal (an object) in the untraced heap. The best alternative is > to fix the pickler with a special that handles Text8Cstrings. I > think this is the cleanest approach. Mika, please try the > following program, which adds a special for Text8CString. I will > put this code into the builtin specials for pickles. > > On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: > >> Looks like we need to fix M3toC.StoT so that it works the same as >> old PM3. The old code works because it constructs a text *in* the >> heap as an ARRAY OF CHAR, that just happens to have its payload >> (the array contents) outside the heap. (Arrays in M3 contain a >> reference to their data). We can play the same trick for >> Text8CString and get things to work properly for you. I will make >> this fix and check it in. >> >> >> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >> >>> Ok, I am about to answer my own email. Here's a little program I >>> wrote: >>> >>> MODULE Main; >>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>> >>> VAR wr := NEW(TextWr.T).init(); >>> toPickle := "pickle this"; >>> BEGIN >>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>> >>> Pickle.Write(wr,toPickle); >>> >>> IO.Put("pickled \""&toPickle&"\"\n"); >>> IO.Put("read back \""& >>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>> &"\"\n"); >>> END Main. >>> >>> === On FreeBSD4 with my ancient, creaky PM3: >>> >>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>> pickled "pickle that" >>> read back "pickle that" >>> >>> === On PPC_DARWIN with the latest CM3: >>> >>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>> pickled "pickle that" >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** >>> >>> Abort >>> >>> === On FreeBSD4 with the latest CM3: >>> >>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>> pickled "pickle that" >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** >>> >>> Abort >>> >>> ============ >>> >>> Diagnosis: >>> >>> The code I mentioned in a previous email declares a Text8CString.T >>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>> in the system, Ctypes.char_star is specifically declared to be an >>> "UNTRACED REF Ctypes.char". According to the specification of >>> Pickle, an UNTRACED REF is pickled as NIL. >>> >>> Generally speaking, you don't see many Text8CString.Ts in the >>> system. >>> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >>> which in turn calls M3toC.StoT. >>> >>> StoT is generally not something you want to call, but it's supposed >>> to be OK here because you're just passing around argv, which won't >>> change. Generally speaking, it ought to be OK to use to convert >>> C strings whose addresses aren't going to change during the lifetime >>> of the program. >>> >>> I think it is *totally unacceptable* that Params.Get returns a >>> "poisoned" TEXT. There is absolutely nothing in any of the >>> interfaces >>> that warns of this fact, and it is surprising to say the least. >>> There is also no simple way of "copying" TEXTs, as it shouldn't >>> ever be required! Finally, there's no way of checking whether a >>> TEXT is a Text8CString.T without importing Text8CString, which is >>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>> >>> What does baffle me a bit is that the code works on the old PM3. >>> It uses the old TextF, which declares >>> >>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>> >>> The old (from PM3, I think it's 1.1.15) M3toC has: >>> >>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>> VAR t := NEW (M3TextWithHeader); >>> BEGIN >>> t.header.typecode := RT0.TextTypecode; >>> t.body.chars := LOOPHOLE (s, ADDRESS); >>> t.body.length := 1 + Cstring.strlen (s); >>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>> END StoT; >>> >>> I'm not entirely sure why the old code works---why isn't the >>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>> In fact the pickler doesn't seem to know anything about TEXTs >>> at all. >>> >>> I see several possible ways of solving the problem. One is to >>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>> interface, there's no "legal" reason not to do that) and make sure >>> Params.Get (and everything else that could remotely be called >>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>> prominent warning signs, both in M3toC and Text8CString that "here >>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>> the C strings. I never liked the CM3 TEXTs, and I like them even >>> less now; I disliked them from the start because they broke pickle >>> compatibility with SRC M3, and now I find that they aren't even >>> compatible with themselves. >>> >>> Modula-3's strengths have always been its utter simplicity >>> and bullet-proof reliability. This stuff, where some objects are >>> more "serializable" than others, reminds me of Java! >>> >>> Does anyone have an opinion as to how this problem ought to be >>> solved? >>> >>> Mika >>> >>> Mika Nystrom writes: >>>> Hello everyone, >>>> >>>> Here's a random question that hopefully someone can answer... >>>> >>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>> >>>> Unless there's some magic I don't understand going on, I am >>>> thinking >>>> that would be the implication of: >>>> >>>> UNSAFE INTERFACE Text8CString; >>>> ... >>>> TYPE >>>> T <: Public; >>>> Public = TEXT OBJECT >>>> str: Ctypes.char_star; >>>> END; >>>> (* The array contains the characters of the text followed by a >>>> '\000'. *) >>>> ... >>>> >>>> I hope someone can set me straight and tell me that no, the >>>> situation >>>> isn't as dire as that---some clever thing somewhere makes it >>>> possible >>>> to Pickle all objects of type TEXT... >>>> >>>> Mika From mika at async.caltech.edu Fri Jul 27 17:04:14 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Jul 2007 08:04:14 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Thu, 26 Jul 2007 12:02:19 EDT." Message-ID: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> Hi Tony, Sorry it took me a day to check up on this. I lost access to my 10.4 system and got my 10.3 back from Apple. You are right, your fix solved the pickle problem. Thank you very much, as always! Yes I realized it was doing something very tricky when I looked at the code... I also tested all my various software, and some of the CM3 programs, on 10.3. I can report the following: 1. The crash in Juno's virtual machine is gone 2. The threads taking 100% no longer do (I think this was the same bug that caused.. deadlock was it?.. on 10.4) 3. And of course the pickling is working great. But... 4. Bresenham still locks up for me. It does this, more often than not, on both 10.3 and 10.4. I'm really surprised it never does it for you! (Although it is true it sometimes work.) 5. I am still using @M3noincremental to run ktok, but it's the *only* program that seems to require it. Almost everything looks really good! Mika Tony Hosking writes: >I'm about to check in the fix. I have tested this with your example >program and things work fine. > >On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: > >> On closer inspection, it is even messier than that. In the old PM3 >> the text that is constructed is allocated in UNTRACED storage >> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >> GC'd, and looks (to the GC) like an (old-style) text literal >> allocated outside the heap. It is harder for us to fake up a text >> literal like this with the new TEXT setup since we'd need to >> allocate, copy, and loophole something that looks like a text >> literal (an object) in the untraced heap. The best alternative is >> to fix the pickler with a special that handles Text8Cstrings. I >> think this is the cleanest approach. Mika, please try the >> following program, which adds a special for Text8CString. I will >> put this code into the builtin specials for pickles. >> >> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >> >>> Looks like we need to fix M3toC.StoT so that it works the same as >>> old PM3. The old code works because it constructs a text *in* the >>> heap as an ARRAY OF CHAR, that just happens to have its payload >>> (the array contents) outside the heap. (Arrays in M3 contain a >>> reference to their data). We can play the same trick for >>> Text8CString and get things to work properly for you. I will make >>> this fix and check it in. >>> >>> >>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>> >>>> Ok, I am about to answer my own email. Here's a little program I >>>> wrote: >>>> >>>> MODULE Main; >>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>> >>>> VAR wr := NEW(TextWr.T).init(); >>>> toPickle := "pickle this"; >>>> BEGIN >>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>> >>>> Pickle.Write(wr,toPickle); >>>> >>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>> IO.Put("read back \""& >>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>> &"\"\n"); >>>> END Main. >>>> >>>> === On FreeBSD4 with my ancient, creaky PM3: >>>> >>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>> pickled "pickle that" >>>> read back "pickle that" >>>> >>>> === On PPC_DARWIN with the latest CM3: >>>> >>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>> pickled "pickle that" >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** >>>> >>>> Abort >>>> >>>> === On FreeBSD4 with the latest CM3: >>>> >>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>> pickled "pickle that" >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** >>>> >>>> Abort >>>> >>>> ============ >>>> >>>> Diagnosis: >>>> >>>> The code I mentioned in a previous email declares a Text8CString.T >>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>> in the system, Ctypes.char_star is specifically declared to be an >>>> "UNTRACED REF Ctypes.char". According to the specification of >>>> Pickle, an UNTRACED REF is pickled as NIL. >>>> >>>> Generally speaking, you don't see many Text8CString.Ts in the >>>> system. >>>> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >>>> which in turn calls M3toC.StoT. >>>> >>>> StoT is generally not something you want to call, but it's supposed >>>> to be OK here because you're just passing around argv, which won't >>>> change. Generally speaking, it ought to be OK to use to convert >>>> C strings whose addresses aren't going to change during the lifetime >>>> of the program. >>>> >>>> I think it is *totally unacceptable* that Params.Get returns a >>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>> interfaces >>>> that warns of this fact, and it is surprising to say the least. >>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>> ever be required! Finally, there's no way of checking whether a >>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>>> >>>> What does baffle me a bit is that the code works on the old PM3. >>>> It uses the old TextF, which declares >>>> >>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>> >>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>> >>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>> VAR t := NEW (M3TextWithHeader); >>>> BEGIN >>>> t.header.typecode := RT0.TextTypecode; >>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>> t.body.length := 1 + Cstring.strlen (s); >>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>> END StoT; >>>> >>>> I'm not entirely sure why the old code works---why isn't the >>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>> In fact the pickler doesn't seem to know anything about TEXTs >>>> at all. >>>> >>>> I see several possible ways of solving the problem. One is to >>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>> interface, there's no "legal" reason not to do that) and make sure >>>> Params.Get (and everything else that could remotely be called >>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>> prominent warning signs, both in M3toC and Text8CString that "here >>>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>> less now; I disliked them from the start because they broke pickle >>>> compatibility with SRC M3, and now I find that they aren't even >>>> compatible with themselves. >>>> >>>> Modula-3's strengths have always been its utter simplicity >>>> and bullet-proof reliability. This stuff, where some objects are >>>> more "serializable" than others, reminds me of Java! >>>> >>>> Does anyone have an opinion as to how this problem ought to be >>>> solved? >>>> >>>> Mika >>>> >>>> Mika Nystrom writes: >>>>> Hello everyone, >>>>> >>>>> Here's a random question that hopefully someone can answer... >>>>> >>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>> >>>>> Unless there's some magic I don't understand going on, I am >>>>> thinking >>>>> that would be the implication of: >>>>> >>>>> UNSAFE INTERFACE Text8CString; >>>>> ... >>>>> TYPE >>>>> T <: Public; >>>>> Public = TEXT OBJECT >>>>> str: Ctypes.char_star; >>>>> END; >>>>> (* The array contains the characters of the text followed by a >>>>> '\000'. *) >>>>> ... >>>>> >>>>> I hope someone can set me straight and tell me that no, the >>>>> situation >>>>> isn't as dire as that---some clever thing somewhere makes it >>>>> possible >>>>> to Pickle all objects of type TEXT... >>>>> >>>>> Mika From hosking at cs.purdue.edu Fri Jul 27 18:40:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Jul 2007 12:40:44 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> References: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> Message-ID: <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> On Jul 27, 2007, at 11:04 AM, Mika Nystrom wrote: > Hi Tony, > > Sorry it took me a day to check up on this. I lost access to my > 10.4 system and got my 10.3 back from Apple. > > You are right, your fix solved the pickle problem. Thank you very > much, > as always! Yes I realized it was doing something very tricky when I > looked at the code... > > I also tested all my various software, and some of the CM3 > programs, on > 10.3. I can report the following: > > 1. The crash in Juno's virtual machine is gone > 2. The threads taking 100% no longer do (I think this was the same > bug that > caused.. deadlock was it?.. on 10.4) > 3. And of course the pickling is working great. Great! > But... > > 4. Bresenham still locks up for me. It does this, more often than > not, > on both 10.3 and 10.4. I'm really surprised it never does it for you! > (Although it is true it sometimes work.) Yes, this problem seems to manifest only on Darwin, and I am seeing the issue with Bresenham as you do. I think it is a VBT issue that I have isolated to the following small program, which works fine for me on Linux, but which has always caused problems on Darwin locking up and not responding (I strongly suspect the Darwin X implementation rather than the threads system, but need still to diagnose the issue): MODULE Main; IMPORT ButtonVBT, HighlightVBT, VBT, TextVBT, Filter, Text, Trestle, BorderedVBT, Compiler, RTIO; PROCEDURE Flip(b: ButtonVBT.T; <*UNUSED*> READONLY cd: VBT.MouseRec) RAISES {}= BEGIN WITH ch = Filter.Child(b), txt = TextVBT.Get(ch) DO IF Text.Equal(txt, "Alpha") THEN TextVBT.Put(ch, "Beta") ELSE TextVBT.Put(ch, "Alpha") END END END Flip; VAR button := ButtonVBT.New(TextVBT.New("Alpha"), Flip); root := BorderedVBT.New(button); BEGIN RTIO.PutText(Compiler.ThisFile()); RTIO.PutChar('\n'); RTIO.PutText(Compiler.ThisPath()); RTIO.PutChar('\n'); RTIO.PutInt(Compiler.ThisLine()); RTIO.PutChar('\n'); RTIO.Flush(); Trestle.Install(root); Trestle.AwaitDelete(root); END Main. > 5. I am still using @M3noincremental to run ktok, but it's the *only* > program that seems to require it. I would like to figure this one out soon, as it really is a worry to me -- I am concerned that the new incremental GC support be as robust as possible and this is the only outstanding issue with it of which I am aware. > > Almost everything looks really good! > > Mika > > Tony Hosking writes: >> I'm about to check in the fix. I have tested this with your example >> program and things work fine. >> >> On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: >> >>> On closer inspection, it is even messier than that. In the old PM3 >>> the text that is constructed is allocated in UNTRACED storage >>> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >>> GC'd, and looks (to the GC) like an (old-style) text literal >>> allocated outside the heap. It is harder for us to fake up a text >>> literal like this with the new TEXT setup since we'd need to >>> allocate, copy, and loophole something that looks like a text >>> literal (an object) in the untraced heap. The best alternative is >>> to fix the pickler with a special that handles Text8Cstrings. I >>> think this is the cleanest approach. Mika, please try the >>> following program, which adds a special for Text8CString. I will >>> put this code into the builtin specials for pickles. >>> >>> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >>> >>>> Looks like we need to fix M3toC.StoT so that it works the same as >>>> old PM3. The old code works because it constructs a text *in* the >>>> heap as an ARRAY OF CHAR, that just happens to have its payload >>>> (the array contents) outside the heap. (Arrays in M3 contain a >>>> reference to their data). We can play the same trick for >>>> Text8CString and get things to work properly for you. I will make >>>> this fix and check it in. >>>> >>>> >>>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>>> >>>>> Ok, I am about to answer my own email. Here's a little program I >>>>> wrote: >>>>> >>>>> MODULE Main; >>>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>>> >>>>> VAR wr := NEW(TextWr.T).init(); >>>>> toPickle := "pickle this"; >>>>> BEGIN >>>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>>> >>>>> Pickle.Write(wr,toPickle); >>>>> >>>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>>> IO.Put("read back \""& >>>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>>> &"\"\n"); >>>>> END Main. >>>>> >>>>> === On FreeBSD4 with my ancient, creaky PM3: >>>>> >>>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> read back "pickle that" >>>>> >>>>> === On PPC_DARWIN with the latest CM3: >>>>> >>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference >>>>> NIL >>>>> *** >>>>> >>>>> Abort >>>>> >>>>> === On FreeBSD4 with the latest CM3: >>>>> >>>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference >>>>> NIL >>>>> *** >>>>> >>>>> Abort >>>>> >>>>> ============ >>>>> >>>>> Diagnosis: >>>>> >>>>> The code I mentioned in a previous email declares a Text8CString.T >>>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>>> in the system, Ctypes.char_star is specifically declared to be an >>>>> "UNTRACED REF Ctypes.char". According to the specification of >>>>> Pickle, an UNTRACED REF is pickled as NIL. >>>>> >>>>> Generally speaking, you don't see many Text8CString.Ts in the >>>>> system. >>>>> This one comes in via Params.Get, which in turn calls >>>>> RTArgs.GetArg, >>>>> which in turn calls M3toC.StoT. >>>>> >>>>> StoT is generally not something you want to call, but it's >>>>> supposed >>>>> to be OK here because you're just passing around argv, which won't >>>>> change. Generally speaking, it ought to be OK to use to convert >>>>> C strings whose addresses aren't going to change during the >>>>> lifetime >>>>> of the program. >>>>> >>>>> I think it is *totally unacceptable* that Params.Get returns a >>>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>>> interfaces >>>>> that warns of this fact, and it is surprising to say the least. >>>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>>> ever be required! Finally, there's no way of checking whether a >>>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>>>> >>>>> What does baffle me a bit is that the code works on the old PM3. >>>>> It uses the old TextF, which declares >>>>> >>>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>>> >>>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>>> >>>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>>> VAR t := NEW (M3TextWithHeader); >>>>> BEGIN >>>>> t.header.typecode := RT0.TextTypecode; >>>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>>> t.body.length := 1 + Cstring.strlen (s); >>>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>>> END StoT; >>>>> >>>>> I'm not entirely sure why the old code works---why isn't the >>>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>>> In fact the pickler doesn't seem to know anything about TEXTs >>>>> at all. >>>>> >>>>> I see several possible ways of solving the problem. One is to >>>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>>> interface, there's no "legal" reason not to do that) and make sure >>>>> Params.Get (and everything else that could remotely be called >>>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>>> prominent warning signs, both in M3toC and Text8CString that "here >>>>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>>> less now; I disliked them from the start because they broke pickle >>>>> compatibility with SRC M3, and now I find that they aren't even >>>>> compatible with themselves. >>>>> >>>>> Modula-3's strengths have always been its utter simplicity >>>>> and bullet-proof reliability. This stuff, where some objects are >>>>> more "serializable" than others, reminds me of Java! >>>>> >>>>> Does anyone have an opinion as to how this problem ought to be >>>>> solved? >>>>> >>>>> Mika >>>>> >>>>> Mika Nystrom writes: >>>>>> Hello everyone, >>>>>> >>>>>> Here's a random question that hopefully someone can answer... >>>>>> >>>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>>> >>>>>> Unless there's some magic I don't understand going on, I am >>>>>> thinking >>>>>> that would be the implication of: >>>>>> >>>>>> UNSAFE INTERFACE Text8CString; >>>>>> ... >>>>>> TYPE >>>>>> T <: Public; >>>>>> Public = TEXT OBJECT >>>>>> str: Ctypes.char_star; >>>>>> END; >>>>>> (* The array contains the characters of the text followed by a >>>>>> '\000'. *) >>>>>> ... >>>>>> >>>>>> I hope someone can set me straight and tell me that no, the >>>>>> situation >>>>>> isn't as dire as that---some clever thing somewhere makes it >>>>>> possible >>>>>> to Pickle all objects of type TEXT... >>>>>> >>>>>> Mika From hosking at cs.purdue.edu Fri Jul 27 19:23:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Jul 2007 13:23:43 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> References: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> Message-ID: <7120B06C-A59A-4509-A857-E5B9A72206E6@cs.purdue.edu> On Jul 27, 2007, at 12:40 PM, Tony Hosking wrote: > > On Jul 27, 2007, at 11:04 AM, Mika Nystrom wrote: > >> Hi Tony, >> >> Sorry it took me a day to check up on this. I lost access to my >> 10.4 system and got my 10.3 back from Apple. >> >> You are right, your fix solved the pickle problem. Thank you very >> much, >> as always! Yes I realized it was doing something very tricky when I >> looked at the code... >> >> I also tested all my various software, and some of the CM3 >> programs, on >> 10.3. I can report the following: >> >> 1. The crash in Juno's virtual machine is gone >> 2. The threads taking 100% no longer do (I think this was the same >> bug that >> caused.. deadlock was it?.. on 10.4) >> 3. And of course the pickling is working great. > > Great! > >> But... >> >> 4. Bresenham still locks up for me. It does this, more often than >> not, >> on both 10.3 and 10.4. I'm really surprised it never does it for >> you! >> (Although it is true it sometimes work.) > > Yes, this problem seems to manifest only on Darwin, and I am seeing > the issue with Bresenham as you do. I think it is a VBT issue that > I have isolated to the following small program, which works fine > for me on Linux, but which has always caused problems on Darwin > locking up and not responding (I strongly suspect the Darwin X > implementation rather than the threads system, but need still to > diagnose the issue): > > MODULE Main; > > IMPORT ButtonVBT, HighlightVBT, VBT, TextVBT, Filter, Text, > Trestle, BorderedVBT, > Compiler, RTIO; > > PROCEDURE Flip(b: ButtonVBT.T; <*UNUSED*> READONLY cd: > VBT.MouseRec) RAISES {}= > BEGIN > WITH ch = Filter.Child(b), txt = TextVBT.Get(ch) DO > IF Text.Equal(txt, "Alpha") THEN > TextVBT.Put(ch, "Beta") > ELSE > TextVBT.Put(ch, "Alpha") > END > END > END Flip; > > VAR > button := ButtonVBT.New(TextVBT.New("Alpha"), Flip); > root := BorderedVBT.New(button); > > BEGIN > RTIO.PutText(Compiler.ThisFile()); RTIO.PutChar('\n'); > RTIO.PutText(Compiler.ThisPath()); RTIO.PutChar('\n'); > RTIO.PutInt(Compiler.ThisLine()); RTIO.PutChar('\n'); > RTIO.Flush(); > Trestle.Install(root); > Trestle.AwaitDelete(root); > END Main. The fix for this program is to set Xquartz defaults as follows (see the manual to see how to do this): defaults write com.apple.x11 wm_click_through -bool true I have still not diagnosed the issue with mentor running Bresenham. > > >> 5. I am still using @M3noincremental to run ktok, but it's the *only* >> program that seems to require it. > > I would like to figure this one out soon, as it really is a worry > to me -- I am concerned that the new incremental GC support be as > robust as possible and this is the only outstanding issue with it > of which I am aware. > >> >> Almost everything looks really good! >> >> Mika >> >> Tony Hosking writes: >>> I'm about to check in the fix. I have tested this with your example >>> program and things work fine. >>> >>> On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: >>> >>>> On closer inspection, it is even messier than that. In the old PM3 >>>> the text that is constructed is allocated in UNTRACED storage >>>> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >>>> GC'd, and looks (to the GC) like an (old-style) text literal >>>> allocated outside the heap. It is harder for us to fake up a text >>>> literal like this with the new TEXT setup since we'd need to >>>> allocate, copy, and loophole something that looks like a text >>>> literal (an object) in the untraced heap. The best alternative is >>>> to fix the pickler with a special that handles Text8Cstrings. I >>>> think this is the cleanest approach. Mika, please try the >>>> following program, which adds a special for Text8CString. I will >>>> put this code into the builtin specials for pickles. >>>> >>>> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >>>> >>>>> Looks like we need to fix M3toC.StoT so that it works the same as >>>>> old PM3. The old code works because it constructs a text *in* the >>>>> heap as an ARRAY OF CHAR, that just happens to have its payload >>>>> (the array contents) outside the heap. (Arrays in M3 contain a >>>>> reference to their data). We can play the same trick for >>>>> Text8CString and get things to work properly for you. I will make >>>>> this fix and check it in. >>>>> >>>>> >>>>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>>>> >>>>>> Ok, I am about to answer my own email. Here's a little program I >>>>>> wrote: >>>>>> >>>>>> MODULE Main; >>>>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>>>> >>>>>> VAR wr := NEW(TextWr.T).init(); >>>>>> toPickle := "pickle this"; >>>>>> BEGIN >>>>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>>>> >>>>>> Pickle.Write(wr,toPickle); >>>>>> >>>>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>>>> IO.Put("read back \""& >>>>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>>>> &"\"\n"); >>>>>> END Main. >>>>>> >>>>>> === On FreeBSD4 with my ancient, creaky PM3: >>>>>> >>>>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> read back "pickle that" >>>>>> >>>>>> === On PPC_DARWIN with the latest CM3: >>>>>> >>>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to >>>>>> dereference NIL >>>>>> *** >>>>>> >>>>>> Abort >>>>>> >>>>>> === On FreeBSD4 with the latest CM3: >>>>>> >>>>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to >>>>>> dereference NIL >>>>>> *** >>>>>> >>>>>> Abort >>>>>> >>>>>> ============ >>>>>> >>>>>> Diagnosis: >>>>>> >>>>>> The code I mentioned in a previous email declares a >>>>>> Text8CString.T >>>>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>>>> in the system, Ctypes.char_star is specifically declared to be an >>>>>> "UNTRACED REF Ctypes.char". According to the specification of >>>>>> Pickle, an UNTRACED REF is pickled as NIL. >>>>>> >>>>>> Generally speaking, you don't see many Text8CString.Ts in the >>>>>> system. >>>>>> This one comes in via Params.Get, which in turn calls >>>>>> RTArgs.GetArg, >>>>>> which in turn calls M3toC.StoT. >>>>>> >>>>>> StoT is generally not something you want to call, but it's >>>>>> supposed >>>>>> to be OK here because you're just passing around argv, which >>>>>> won't >>>>>> change. Generally speaking, it ought to be OK to use to convert >>>>>> C strings whose addresses aren't going to change during the >>>>>> lifetime >>>>>> of the program. >>>>>> >>>>>> I think it is *totally unacceptable* that Params.Get returns a >>>>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>>>> interfaces >>>>>> that warns of this fact, and it is surprising to say the least. >>>>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>>>> ever be required! Finally, there's no way of checking whether a >>>>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>>>> an UNSAFE INTERFACE, which of course is illegal in a safe >>>>>> MODULE!! >>>>>> >>>>>> What does baffle me a bit is that the code works on the old PM3. >>>>>> It uses the old TextF, which declares >>>>>> >>>>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>>>> >>>>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>>>> >>>>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>>>> VAR t := NEW (M3TextWithHeader); >>>>>> BEGIN >>>>>> t.header.typecode := RT0.TextTypecode; >>>>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>>>> t.body.length := 1 + Cstring.strlen (s); >>>>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>>>> END StoT; >>>>>> >>>>>> I'm not entirely sure why the old code works---why isn't the >>>>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>>>> In fact the pickler doesn't seem to know anything about TEXTs >>>>>> at all. >>>>>> >>>>>> I see several possible ways of solving the problem. One is to >>>>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>>>> interface, there's no "legal" reason not to do that) and make >>>>>> sure >>>>>> Params.Get (and everything else that could remotely be called >>>>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>>>> prominent warning signs, both in M3toC and Text8CString that >>>>>> "here >>>>>> be demons". Another is to revert to the SRC method of >>>>>> LOOPHOLEing >>>>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>>>> less now; I disliked them from the start because they broke >>>>>> pickle >>>>>> compatibility with SRC M3, and now I find that they aren't even >>>>>> compatible with themselves. >>>>>> >>>>>> Modula-3's strengths have always been its utter simplicity >>>>>> and bullet-proof reliability. This stuff, where some objects are >>>>>> more "serializable" than others, reminds me of Java! >>>>>> >>>>>> Does anyone have an opinion as to how this problem ought to be >>>>>> solved? >>>>>> >>>>>> Mika >>>>>> >>>>>> Mika Nystrom writes: >>>>>>> Hello everyone, >>>>>>> >>>>>>> Here's a random question that hopefully someone can answer... >>>>>>> >>>>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>>>> >>>>>>> Unless there's some magic I don't understand going on, I am >>>>>>> thinking >>>>>>> that would be the implication of: >>>>>>> >>>>>>> UNSAFE INTERFACE Text8CString; >>>>>>> ... >>>>>>> TYPE >>>>>>> T <: Public; >>>>>>> Public = TEXT OBJECT >>>>>>> str: Ctypes.char_star; >>>>>>> END; >>>>>>> (* The array contains the characters of the text followed by a >>>>>>> '\000'. *) >>>>>>> ... >>>>>>> >>>>>>> I hope someone can set me straight and tell me that no, the >>>>>>> situation >>>>>>> isn't as dire as that---some clever thing somewhere makes it >>>>>>> possible >>>>>>> to Pickle all objects of type TEXT... >>>>>>> >>>>>>> Mika From elmstb at aon.at Wed Jul 4 20:33:14 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 18:33:14 -0000 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468BE796.8020802@aon.at> It seems to be the same message, which I have sent to you. Has there been anything new you wanted to tell me? Is the setjmp/longjmp replacement of interest? Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > However this may be less favourable than using makecontext since the > assembler routines will only work on i386 hardware. > Moreover setjmp/longjmp are said that they may cause the loss of > assignents, because they do not save certain registers(cx,dx) -> see > "Exception semantics" at > http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. > Nevertheless possible future changes on make/get/setcontext will not be > able to affect Modula-3 when extracting the SP from the context record > any more if it does not rely on glibc functions. > Another solution is to link against the old glibc files (unpacked into > /lib/anc): > > >> ldd $(which m3build) >> > linux-gate.so.1 => (0xffffe000) > libm3front.so.1 => > /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) > libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) > libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) > /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) > > Please tell me if you are intereseted in any of both solutions. > I would suppose a solution for CM3 not to differ that much. > > Yours, > Elmar Stellnberger > > > > Tony Hosking wrote: > >> I have a question that may influence the direction we take with >> user-level threading support. Currently, user-level threading is >> broken on platforms that implement secure setjmp/longjmp via >> encryption since hacking the jump buffers the way we currently do for >> user-level threading triggers longjmp errors. A better alternative is >> to use makecontext/getcontext/setcontext on platforms that support it. >> For example, I know of the following situation for the targets I track: >> >> Target System (pthreads) threads User (setjmp/longjmp) threads User >> (getcontext/setcontext) threads >> >> LINUXLIBC6 YES NO unimplemented >> SOLgnu YES unimplemented YES (but not using makecontext) >> PPC_DARWIN YES NO no getcontext/setcontext >> I386_DARWIN YES NO no getcontext/setcontext >> FreeBSD NO YES unimplemented >> >> Ideally, we would implement all user-level threading using makecontext >> and friends, but my question is how many of our user-level threading >> targets actually support that API? One strategy would be to >> re-implement user-level threading using makecontext, etc., but fake up >> makecontext support, etc., on those targets that don't have it. >> >> I would hate to lose the user-level thread support just because it >> makes sense in some situations (e.g., embedded, uni-processor). >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Fri Jul 13 18:17:34 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 13 Jul 2007 16:17:34 -0000 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <20070713161515.GC98227@ted.stsp.lan> On Fri, Jul 13, 2007 at 10:43:01AM -0500, Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts to > use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. No. It's a known issue. > Any pointers to documentation on what CVS really wants here? http://ximbiot.com/cvs/manual/cvs-1.12.6/cvs_18.html#SEC168 -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rcoleburn at scires.com Thu Jul 19 20:56:22 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 19 Jul 2007 18:56:22 -0000 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F7BAD.1E75.00D7.1@scires.com> Tony: I'd like to better understand the implications of your change as I do use LONGINT as an index in some applications. 1. On a computer with a 32-bit word size, will LONGINT be 32 bits or 64 bits? 2. I assume on a computer with a 64-bit word size, LONGINT will be 64 bits. Is there an option to get a 32-bit integer on these machines? 3. Would it make sense to keep LONGINT at 32-bits and make a new type, say LONGINT64, at 64-bits? Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> Tony Hosking 7/18/2007 11:53 PM >>> I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 20 22:48:34 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 20:48:34 -0000 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FDFDE.9020201@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FDFDE.9020201@wichita.edu> Message-ID: <05CD4EBC-E1C6-4BB7-919C-8032B5265609@cs.purdue.edu> I think I am coming around to Rodney's position. We should consider INTEGER and LONGINT assignable under the current rules for subranges. Thus, INTEGER := LONGINT will cause a range check (and underlying conversion of the integer value from BITSIZE(LONGINT) to BITSIZE(INTEGER)), whereas LONGINT := INTEGER will need not check (though the conversion will be necessary to extend sign as expected). I believe this functionality can easily be implemented in the current compiler. Also, I am willing to allow indexing of arrays using LONGINT-based ordinals for the index type. The usual restrictions on array size will obtain, and zero-based array indexes will be computed into integer offsets. Thus, for an array indexed [minL..maxL] where minL and maxL have base type LONGINT, the offset will be computed as: index - minL and converted to an INTEGER value to index the array. Because of the sizing restriction, index - minL must be expressible as an INTEGER. Here are my revised notes: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longint.txt URL: -------------- next part -------------- On Jul 19, 2007, at 6:04 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> On Jul 19, 2007, at 4:33 PM, Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >> There is no implicit conversion for floats. The danger with >> implicit conversion for integers is that it would not be >> portable: you would get different behavior on different machines >> for the same code. Better to make the conversion explicit so >> that programmers are prepared for the range check to fail. > > But is this argument any stronger for requiring explicit conversions > for INTEGER/LONGINT assignments than for assigning to subranges? > Many assignments in the language now, without any type conversion, > admit the possibility of RT range errors. And these can be dependent > on the size of INTEGER too. Consider: > > VAR V : [ 0 .. 65535 ] ; > VAR I : CARDINAL ; > ... > V := I DIV 2 ; > > I think for portability, the principle that the static semantics > should be > the same for all sizes of INTEGER (and LONGINT too) is as much as > we can > hope for. Certainly, there are already countless ways the integer > size can > change the dynamic semantics of a program. > > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From mika at async.caltech.edu Mon Jul 2 12:35:48 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 02 Jul 2007 03:35:48 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Thu, 28 Jun 2007 10:53:25 EDT." Message-ID: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:03:42 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:03:42 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:05:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:05:36 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: <3B964979-AD2A-41FD-8522-3B1D00D9CE9A@cs.purdue.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:49:57 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:49:57 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: <39E88F42-57CE-4AE0-8ED8-AF955B6A0E26@cs.purdue.edu> In follow up to my previous message, I think I may have a simpler fix. Can you please try the latest version of ThreadPosix.m3 that I just checked in. Unfortunately, I don't have a user-level threads system on which to try (Linux is broken because setjmp/longjmp use encryption to prevent stack-smashing security exploits), and my Solaris boxes are not available right now. 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 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? From dabenavidesd at yahoo.es Mon Jul 2 18:05:22 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 2 Jul 2007 18:05:22 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: Message-ID: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> Hi: In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the same problem is happensg, with the message of the RTCollector danielb at danielb-desktop:~$ mentor *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/runtime/common/RTCollector.m3", line 2310 *** Aborted danielb at danielb-desktop:~$ With the @M3noincremental runs fine, @M3nogc also doesnt break. --- Tony Hosking wrote: > 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, === message truncated === ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From hosking at cs.purdue.edu Mon Jul 2 21:50:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 15:50:44 -0400 Subject: [M3devel] strange errors... In-Reply-To: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> References: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> Message-ID: This problem has been fixed by the most recent update to RTCollector.m3, with respect to handling of weak references. On Jul 2, 2007, at 12:05 PM, Daniel Alejandro Benavides D. wrote: > Hi: > In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the > same problem is happensg, with the message of the > RTCollector > > danielb at danielb-desktop:~$ mentor > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", > line 2310 > *** > > Aborted > > danielb at danielb-desktop:~$ > > With the @M3noincremental runs fine, @M3nogc also > doesnt break. > > > > --- Tony Hosking wrote: > >> 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, > === message truncated === > > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. > http://es.voice.yahoo.com From hosking at cs.purdue.edu Mon Jul 2 22:01:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 16:01:26 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: Is there any chance this error is related to the fix I just made with respect to weak references? I am going to get a user-level setup working for my LINUXLIBC6 builds, so as to try and track this problem down. 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 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? From mika at async.caltech.edu Tue Jul 3 11:13:23 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 03 Jul 2007 02:13:23 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Mon, 02 Jul 2007 11:49:57 EDT." <39E88F42-57CE-4AE0-8ED8-AF955B6A0E26@cs.purdue.edu> Message-ID: <200707030913.l639DNDc012408@camembert.async.caltech.edu> Wow! It works! I am able to compile the various stages of bootstrap as well as run Juno, mentor, etc., without any @M3 hacks, on FreeBSD with the user-level threads, as of this afternoon's checkout (around 3 p.m. Pacific). On my quest to move on from various dusty PM3 decks, I am still struggling with some of my own code, which seems to be having issues with pickles, network objects, trestle, m3gdb, and a few other odds and ends, but I will return to those at a later date. All the garbage collector issues that I am aware of seem resolved on FreeBSD. A big thanks!!! Mika P.S. Tony, if you'd like a testing account on my home machine, which is running FreeBSD5.5-RELEASE/i386, just let me know. Of course I'm happy to try updating and compiling things, too. Tony Hosking writes: >In follow up to my previous message, I think I may have a simpler >fix. Can you please try the latest version of ThreadPosix.m3 that I >just checked in. Unfortunately, I don't have a user-level threads >system on which to try (Linux is broken because setjmp/longjmp use >encryption to prevent stack-smashing security exploits), and my >Solaris boxes are not available right now. > >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 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? From hosking at cs.purdue.edu Tue Jul 3 17:28:59 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Jul 2007 11:28:59 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707030913.l639DNDc012408@camembert.async.caltech.edu> References: <200707030913.l639DNDc012408@camembert.async.caltech.edu> Message-ID: <58811923-05C1-45CF-A774-DE15BABD93B5@cs.purdue.edu> Excellent! The problem was in the way the weak references implementation squirrels away traced references and hides them from the run-time system. In my digging I have also discovered that there appears to be some sort of race in the VBT code that leads to double-release of a lock. It appears not to be GC-related. Is anyone familiar enough with the VBT code to diagnose this? It always happens at the same place: #0 ThreadPThread__Die (M3_AcxOUs_lineno=167, M3_Bd56fi_msg=0x1061088) at ThreadPThread.m3:1238 #1 0x010360d7 in ThreadPThread__InnerUnlockMutex (M3_AYIbX3_m=0xb4d127c4, M3_BXP32l_self=0xb4d1e010) at ThreadPThread.m3:167 #2 0x010362ee in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0xb4d127c4) at ThreadPThread.m3:188 #3 0x004dca26 in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d127c4, M3_BFdKo9_ch=0xb4d15164, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:799 #4 0x004d51dd in VBT__Sync (M3_BJ2YpW_v=0xb4d15164, M3_AicXUJ_wait=1 '\001') at VBT.m3:1167 #5 0x00524838 in JoinedVBT__Sync (M3_B2daE0_v=0xb4d12654, M3_BFdKo9_ch=0xb4d12730, M3_AicXUJ_wait=1 '\001') at JoinedVBT.m3:101 #6 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d12730, M3_BFdKo9_ch=0xb4d126b4, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #7 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d126b4, M3_BFdKo9_ch=0xb24c5e48, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #8 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb24c5e48, M3_BFdKo9_ch=0xb4d1e0b0, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #9 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d1e0b0, M3_BFdKo9_ch=0xb4d1e31c, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #10 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d1e31c, M3_BFdKo9_ch=0xb4d1e1a0, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #11 0x004d51dd in VBT__Sync (M3_BJ2YpW_v=0xb4d1e1a0, M3_AicXUJ_wait=1 '\001') at VBT.m3:1167 #12 0x00bcc273 in MGV__MGRedisplay (M3_AdEaVQ_v=0xb4d1e1a0, M3_A0Kbc5_br=0xcf2600) at MGV.m3:146 #13 0x00bb7fa1 in Animate__DoAnimation (M3_CCfZY3_t=0xb2506534, M3_BUucNs_time=0.157132864, M3_BUucNs_timePrev=0.156615973, M3_AdEaVQ_v=0xb4d1e1a0, M3_DsL7Zz_mg=0x0) at Animate.m3:57 #14 0x00bb80eb in Animate__Do (M3_CCfZY3_t=0xb2506534, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0xb4d1e1a0, M3_BUucNs_duration=1) at Animate.m3:74 #15 0x00bcd5c6 in MGV__Animation (M3_AdEaVQ_v=0xb4d1e1a0, M3_BUucNs_duration=1) at MGV.m3:313 #16 0x0031a3f3 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0xb4d1e0b0, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at GraphVBT.m3:656 #17 0x08077aec in PackingView3__Probe (M3_ClPWAg_view=0xb24c5e48, M3_AcxOUs_bin=1, M3_BUucNs_total=0.972417712) at PackingView3.m3:68 #18 0x0806c76c in BinpackIE__OEDispatcher (M3_Ao6Rbg_v=0xb24c5e48, M3_Af40ku_evt=0xb7fda068) at BinpackIE.m3:96 #19 0x001f83fb in Zeus__ViewThread (M3_BH3Tll_self=0xb4d22030) at Zeus.m3:331 #20 0x01038d80 in ThreadPThread__RunThread (M3_EkbOya_me=0x84c5b98) at ThreadPThread.m3:547 #21 0x01038895 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x84c5b98) at ThreadPThread.m3:517 #22 0x42a2a3db in start_thread () from /lib/libpthread.so.0 #23 0x4296f26e in clone () from /lib/libc.so.6 On Jul 3, 2007, at 5:13 AM, Mika Nystrom wrote: > > Wow! It works! I am able to compile the various stages of bootstrap > as well as run Juno, mentor, etc., without any @M3 hacks, on FreeBSD > with the user-level threads, as of this afternoon's checkout (around > 3 p.m. Pacific). On my quest to move on from various dusty PM3 > decks, I am still struggling with some of my own code, which seems > to be having issues with pickles, network objects, trestle, m3gdb, > and a few other odds and ends, but I will return to those at a later > date. All the garbage collector issues that I am aware of seem > resolved on FreeBSD. A big thanks!!! > > Mika > > P.S. Tony, if you'd like a testing account on my home machine, which > is running FreeBSD5.5-RELEASE/i386, just let me know. Of course > I'm happy to try updating and compiling things, too. > > Tony Hosking writes: >> In follow up to my previous message, I think I may have a simpler >> fix. Can you please try the latest version of ThreadPosix.m3 that I >> just checked in. Unfortunately, I don't have a user-level threads >> system on which to try (Linux is broken because setjmp/longjmp use >> encryption to prevent stack-smashing security exploits), and my >> Solaris boxes are not available right now. >> >> 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 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? From hosking at cs.purdue.edu Tue Jul 3 18:42:16 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Jul 2007 12:42:16 -0400 Subject: [M3devel] User-level threading Message-ID: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> I have a question that may influence the direction we take with user- level threading support. Currently, user-level threading is broken on platforms that implement secure setjmp/longjmp via encryption since hacking the jump buffers the way we currently do for user-level threading triggers longjmp errors. A better alternative is to use makecontext/getcontext/setcontext on platforms that support it. For example, I know of the following situation for the targets I track: Target System (pthreads) threads User (setjmp/longjmp) threads User (getcontext/setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES unimplemented YES (but not using makecontext) PPC_DARWIN YES NO no getcontext/setcontext I386_DARWIN YES NO no getcontext/setcontext FreeBSD NO YES unimplemented Ideally, we would implement all user-level threading using makecontext and friends, but my question is how many of our user- level threading targets actually support that API? One strategy would be to re-implement user-level threading using makecontext, etc., but fake up makecontext support, etc., on those targets that don't have it. I would hate to lose the user-level thread support just because it makes sense in some situations (e.g., embedded, uni-processor). From dragisha at m3w.org Tue Jul 3 23:37:54 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 03 Jul 2007 23:37:54 +0200 Subject: [M3devel] myId and inCritical.... Message-ID: <1183498674.9419.3.camel@faramir.m3w.org> Hallelujah! -- Dragi?a Duri? From mika at async.caltech.edu Wed Jul 4 14:10:39 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 04 Jul 2007 05:10:39 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Sun, 24 Jun 2007 10:38:34 EDT." Message-ID: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Hi again! I was able to boot the CVS head of CM3 on my Mac just fine now, using the cm3.cfg you sent me. I am still running the old OS (Panther, is it?) so I tried doing it the hard way instead of using your binaries, and I got something that works pretty well. Mentor and Juno work, at least, and that's usually a good indicator that one is on the right track... But (of course there's a "but"), I am still falling down on my very first reported bug, namely this local ktok program. I still, after all that you've done, find that it dies on an illegal instruction on the Macintosh (I am running 10.3 on a Powerbook). The problem goes away if I use either @M3nogc or @M3noincremental. The gdb backtrace is not very helpful: it says the program is crashing somewhere in a text processing module, creating an iterator on a sorted table. Sorry to do this but I am feeling a bit clueless, so if you're interested and have the time to look into it, I have set up a minimal test here: http://www.async.caltech.edu/~mika/ktok_example.tgz Unfortunately, ktok itself depends on a bunch of packages. To build this, set your CM3 environment variable to anything (1 works) and just "make" (GNU make, please). Set the DEBUGLEVEL environment variable to "10" for a bit more output (not much). The very last step (compiling package cit_parse) fails for me... Specifically, the step is: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 WELCOME! GOT TOKPARAMS! GOT TOKENS GOT SUBS! "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 4: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 Looking a bit closer: [lapdog:~/t/cit_parse/src] mika% gdb /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 Starting program: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 Reading symbols for shared libraries . done WELCOME! GOT TOKPARAMS! GOT TOKENS GOT SUBS! Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x00b111c8 in ?? () (gdb) where #0 0x00b111c8 in ?? () #1 0x000120e4 in TextSubs__Apply (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at TextSubs.m3:64 #2 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 #3 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 #4 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 #5 0x00001ecc in main (argc=4, argv=0xbffffadc, envp=0xbffffaf0) at _m3main.mc:4 (gdb) Also: PROCEDURE Apply(self: T; src: TEXT): TEXT = VAR wr := TextWr.New(); c: CHAR; ind, pos, lastFlushed: INTEGER := 0; textLen := Text.Length(src); iter: SortedTextTextTbl.Iterator; original, replacement: TEXT; key, prefix: TEXT; PROCEDURE Flush() = BEGIN Wr.PutText(wr, Text.Sub(src, lastFlushed, pos - lastFlushed)); END Flush; BEGIN WHILE pos < textLen DO c := Text.GetChar(src, pos); IF c IN self.starts THEN Debug.Out("analysing: " & Text.Sub(src, pos), 100); iter := self.tbl.iterateOrdered(); (* line 64 *) ind := pos; original := ""; REPEAT INC(ind); ... I am mystified as to why gdb would say that RTLinker__RunMainBody would be calling TextSubs__Apply. With @M3nogc or @M3noincremental, all is well... I will see if I can figure out more, but this problem just doesn't seem to want to go away. To the best of my knowledge, ktok doesn't use any UNSAFE code (outside of whatever's in libm3 of course). Mika 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: > >cd ~/cm3/scripts >./do-cm3-std.sh realclean >./do-cm3-std.sh buildship > >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 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? From wagner at elegosoft.com Wed Jul 4 17:32:12 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 4 Jul 2007 17:32:12 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> References: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Message-ID: <37423.194.138.127.36.1183563132.squirrel@mail.elegosoft.com> On Wed, July 4, 2007 2:10 pm, Mika Nystrom wrote: > Hi again! > > I was able to boot the CVS head of CM3 on my Mac just fine now, > using the cm3.cfg you sent me. I am still running the old OS > (Panther, is it?) so I tried doing it the hard way instead of using > your binaries, and I got something that works pretty well. Mentor > and Juno work, at least, and that's usually a good indicator that > one is on the right track... > > But (of course there's a "but"), I am still falling down on my very > first reported bug, namely this local ktok program. I still, after > all that you've done, find that it dies on an illegal instruction > on the Macintosh (I am running 10.3 on a Powerbook). > > The problem goes away if I use either @M3nogc or @M3noincremental. > The gdb backtrace is not very helpful: it says the program is > crashing somewhere in a text processing module, creating an iterator > on a sorted table. > > Sorry to do this but I am feeling a bit clueless, so if you're > interested and have the time to look into it, I have set up a minimal > test here: > > http://www.async.caltech.edu/~mika/ktok_example.tgz > > Unfortunately, ktok itself depends on a bunch of packages. > > To build this, set your CM3 environment variable to anything (1 > works) and just "make" (GNU make, please). Set the DEBUGLEVEL > environment variable to "10" for a bit more output (not much). The > very last step (compiling package cit_parse) fails for me... > Specifically, the step is: > > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime > error: exit 4: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o > PRSTok.i3 > > Looking a bit closer: > > [lapdog:~/t/cit_parse/src] mika% gdb > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) > Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 > Starting program: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o > PRSTok.i3 > Reading symbols for shared libraries . done > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > > Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. > 0x00b111c8 in ?? () > (gdb) where > #0 0x00b111c8 in ?? () > #1 0x000120e4 in TextSubs__Apply (M3_CN69dV_self=0xb26434, > M3_Bd56fi_src=0xb40be0) at TextSubs.m3:64 > #2 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at > RTLinker.m3:399 > #3 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 > #4 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 > #5 0x00001ecc in main (argc=4, argv=0xbffffadc, envp=0xbffffaf0) at > _m3main.mc:4 > (gdb) > > Also: > > PROCEDURE Apply(self: T; src: TEXT): TEXT = > VAR > wr := TextWr.New(); > c: CHAR; > ind, pos, lastFlushed: INTEGER := 0; > textLen := Text.Length(src); > iter: SortedTextTextTbl.Iterator; > original, replacement: TEXT; > key, prefix: TEXT; > PROCEDURE Flush() = > BEGIN > Wr.PutText(wr, Text.Sub(src, lastFlushed, pos - lastFlushed)); > END Flush; > BEGIN > WHILE pos < textLen DO > c := Text.GetChar(src, pos); > IF c IN self.starts THEN > Debug.Out("analysing: " & Text.Sub(src, pos), 100); > iter := self.tbl.iterateOrdered(); (* line 64 *) > ind := pos; > original := ""; > REPEAT > INC(ind); > ... > > I am mystified as to why gdb would say that RTLinker__RunMainBody > would be calling TextSubs__Apply. > > With @M3nogc or @M3noincremental, all is well... > > I will see if I can figure out more, but this problem just doesn't > seem to want to go away. To the best of my knowledge, ktok doesn't > use any UNSAFE code (outside of whatever's in libm3 of course). I cannot really tell you why there's a bad instruction in some of the module initialization code, but the RT linker is executing all the module bodies in correct order at the start of the program (at least it tries to :). So probably TextSubs.Apply is called from some module initialization code. Have you tried to run the program with @M3tracelinker to get some context to that call? It should print ouy all module names... This _may_ be helpful. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From elmstb at aon.at Wed Jul 4 20:12:04 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 20:12:04 +0200 Subject: [M3devel] User-level threading In-Reply-To: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> Message-ID: <468BE2F4.7010805@aon.at> Not long ago I have fixed this problem by replacing setjmp/longjmp with my own i386 - implementations of these functions for SRC-M3. The result seems to be stable and correct. However this may be less favourable than using makecontext since the assembler routines will only work on i386 hardware. Moreover setjmp/longjmp are said that they may cause the loss of assignents, because they do not save certain registers(cx,dx) -> see "Exception semantics" at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. Nevertheless possible future changes on make/get/setcontext will not be able to affect Modula-3 when extracting the SP from the context record any more if it does not rely on glibc functions. Another solution is to link against the old glibc files (unpacked into /lib/anc): > ldd $(which m3build) linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) Please tell me if you are intereseted in any of both solutions. I would suppose a solution for CM3 not to differ that much. Yours, Elmar Stellnberger Tony Hosking wrote: > I have a question that may influence the direction we take with > user-level threading support. Currently, user-level threading is > broken on platforms that implement secure setjmp/longjmp via > encryption since hacking the jump buffers the way we currently do for > user-level threading triggers longjmp errors. A better alternative is > to use makecontext/getcontext/setcontext on platforms that support it. > For example, I know of the following situation for the targets I track: > > Target System (pthreads) threads User (setjmp/longjmp) threads User > (getcontext/setcontext) threads > > LINUXLIBC6 YES NO unimplemented > SOLgnu YES unimplemented YES (but not using makecontext) > PPC_DARWIN YES NO no getcontext/setcontext > I386_DARWIN YES NO no getcontext/setcontext > FreeBSD NO YES unimplemented > > Ideally, we would implement all user-level threading using makecontext > and friends, but my question is how many of our user-level threading > targets actually support that API? One strategy would be to > re-implement user-level threading using makecontext, etc., but fake up > makecontext support, etc., on those targets that don't have it. > > I would hate to lose the user-level thread support just because it > makes sense in some situations (e.g., embedded, uni-processor). > > > From elmstb at aon.at Wed Jul 4 20:31:50 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 20:31:50 +0200 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468BE796.8020802@aon.at> It seems to be the same message, which I have sent to you. Has there been anything new you wanted to tell me? Is the setjmp/longjmp replacement of interest? Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > However this may be less favourable than using makecontext since the > assembler routines will only work on i386 hardware. > Moreover setjmp/longjmp are said that they may cause the loss of > assignents, because they do not save certain registers(cx,dx) -> see > "Exception semantics" at > http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. > Nevertheless possible future changes on make/get/setcontext will not be > able to affect Modula-3 when extracting the SP from the context record > any more if it does not rely on glibc functions. > Another solution is to link against the old glibc files (unpacked into > /lib/anc): > > >> ldd $(which m3build) >> > linux-gate.so.1 => (0xffffe000) > libm3front.so.1 => > /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) > libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) > libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) > /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) > > Please tell me if you are intereseted in any of both solutions. > I would suppose a solution for CM3 not to differ that much. > > Yours, > Elmar Stellnberger > > > > Tony Hosking wrote: > >> I have a question that may influence the direction we take with >> user-level threading support. Currently, user-level threading is >> broken on platforms that implement secure setjmp/longjmp via >> encryption since hacking the jump buffers the way we currently do for >> user-level threading triggers longjmp errors. A better alternative is >> to use makecontext/getcontext/setcontext on platforms that support it. >> For example, I know of the following situation for the targets I track: >> >> Target System (pthreads) threads User (setjmp/longjmp) threads User >> (getcontext/setcontext) threads >> >> LINUXLIBC6 YES NO unimplemented >> SOLgnu YES unimplemented YES (but not using makecontext) >> PPC_DARWIN YES NO no getcontext/setcontext >> I386_DARWIN YES NO no getcontext/setcontext >> FreeBSD NO YES unimplemented >> >> Ideally, we would implement all user-level threading using makecontext >> and friends, but my question is how many of our user-level threading >> targets actually support that API? One strategy would be to >> re-implement user-level threading using makecontext, etc., but fake up >> makecontext support, etc., on those targets that don't have it. >> >> I would hate to lose the user-level thread support just because it >> makes sense in some situations (e.g., embedded, uni-processor). >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jul 4 22:12:47 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Jul 2007 16:12:47 -0400 Subject: [M3devel] User-level threading In-Reply-To: <468BE796.8020802@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> <468BE796.8020802@aon.at> Message-ID: In looking at things again, I am more and more convinced that ThreadPosix should be implemented against the standard API for makecontext/getcontext/setcontext/swapcontext. Platforms that do not provide these will need to provide an equivalent implementation of these routines, similar to what you suggest. Right now, I know all of SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary support. On Jul 4, 2007, at 2:31 PM, Elmar Stellnberger wrote: > It seems to be the same message, which I have sent to you. > Has there been anything new you wanted to tell me? > Is the setjmp/longjmp replacement of interest? > > Elmar Stellnberger wrote: >> Not long ago I have fixed this problem by replacing setjmp/longjmp >> with my own i386 - implementations of these functions for SRC-M3. >> The result seems to be stable and correct. However this may be >> less favourable than using makecontext since the assembler >> routines will only work on i386 hardware. Moreover setjmp/longjmp >> are said that they may cause the loss of assignents, because they >> do not save certain registers(cx,dx) -> see "Exception semantics" >> at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/ >> restrictions.html. Nevertheless possible future changes on make/ >> get/setcontext will not be able to affect Modula-3 when extracting >> the SP from the context record any more if it does not rely on >> glibc functions. Another solution is to link against the old glibc >> files (unpacked into /lib/anc): >>> ldd $(which m3build) >> linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/ >> lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so. >> 6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/ >> libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) >> Please tell me if you are intereseted in any of both solutions. I >> would suppose a solution for CM3 not to differ that much. Yours, >> Elmar Stellnberger Tony Hosking wrote: >>> I have a question that may influence the direction we take with >>> user-level threading support. Currently, user-level threading is >>> broken on platforms that implement secure setjmp/longjmp via >>> encryption since hacking the jump buffers the way we currently do >>> for user-level threading triggers longjmp errors. A better >>> alternative is to use makecontext/getcontext/setcontext on >>> platforms that support it. For example, I know of the following >>> situation for the targets I track: Target System (pthreads) >>> threads User (setjmp/longjmp) threads User (getcontext/ >>> setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES >>> unimplemented YES (but not using makecontext) PPC_DARWIN YES NO >>> no getcontext/setcontext I386_DARWIN YES NO no getcontext/ >>> setcontext FreeBSD NO YES unimplemented Ideally, we would >>> implement all user-level threading using makecontext and friends, >>> but my question is how many of our user-level threading targets >>> actually support that API? One strategy would be to re-implement >>> user-level threading using makecontext, etc., but fake up >>> makecontext support, etc., on those targets that don't have it. I >>> would hate to lose the user-level thread support just because it >>> makes sense in some situations (e.g., embedded, uni-processor). > From wagner at elegosoft.com Wed Jul 4 22:25:16 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 4 Jul 2007 22:25:16 +0200 Subject: [M3devel] User-level threading In-Reply-To: References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> <468BE796.8020802@aon.at> Message-ID: <20070704202516.GA26977@elegosoft.com> On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: > In looking at things again, I am more and more convinced that > ThreadPosix should be implemented against the standard API for > makecontext/getcontext/setcontext/swapcontext. Platforms that do not > provide these will need to provide an equivalent implementation of > these routines, similar to what you suggest. Right now, I know all of > SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary > support. I think a `standard' implementation using makecontext/getcontext/... would be the best. For those platforms that do not support that, we can still use a C or assembler implementation. I would strongly vote for keeping user-level threading, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Wed Jul 4 23:35:13 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 Jul 2007 23:35:13 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Message-ID: <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Hi: I take the sources from the your web page and type make on the top of the directory v and end in this message: ===> cit_parse --- building in LINUXLIBC6 --- ignoring override("cit_parse", "/home/danielb/Desktop/v") /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x4000b19f *** "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 1536: /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 --procedure-- -line- -file--- exec -- _exec 20 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _xCons 37 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tCons 81 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tConsUn 82 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl Token 85 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl include_dir 3 /home/danielb/Desktop/v/cit_parse/src/m3makefile 5 /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args Fatal Error: package build failed Well that was because of the lack of the file PRS.t Searching I noticed that the file is in v/cit_parse/src/PRS.t and made a copy on v/parserlib/ktok/src directory Then try make again and but this time, get this: cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e new source -> compiling PRSTok.m3 "../LINUXLIBC6/PRSTok.m3", line 1: syntax error: missing INTERFACE or MODULE keyword "../LINUXLIBC6/PRSTok.m3", line 1: unable to find interface () "../LINUXLIBC6/PRSTok.m3", line 1: warning: file name (PRSTok.m3) doesn't match module name () 2 errors and 1 warning encountered new source -> compiling PRSTok.i3 new source -> compiling PRSLex.i3 new source -> compiling PRSLex.m3 new source -> compiling PRSParse.i3 new source -> compiling PRSParse.m3 new source -> compiling PRSLexStd.i3 new source -> compiling PRSLexStd.m3 new source -> compiling PRSParseStd.i3 new source -> compiling PRSParseStd.m3 new source -> compiling CHPTok.i3 new source -> compiling CHPTok.m3 "../LINUXLIBC6/CHPTok.m3", line 36: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered new source -> compiling CHPLex.i3 new source -> compiling CHPLex.m3 new source -> compiling CHPParse.i3 new source -> compiling CHPParse.m3 new source -> compiling CHPLexStd.i3 new source -> compiling CHPLexStd.m3 new exporters -> recompiling PRSTok.i3 compilation failed => not building library "libcit_parse.a" Fatal Error: package build failed danielb at danielb-desktop:~/code/caltech-parser/v2/v$ It seems PRSTok.m3 does exist on v/cit_parse/LINUXLIBC6 but is an empty file. Maybe Im not doing the right steps? Thanks --- Mika Nystrom wrote: > Hi again! > > I was able to boot the CVS head of CM3 on my Mac > just fine now, > using the cm3.cfg you sent me. I am still running > the old OS > (Panther, is it?) so I tried doing it the hard way > instead of using > your binaries, and I got something that works pretty > well. Mentor > and Juno work, at least, and that's usually a good > indicator that > one is on the right track... > > But (of course there's a "but"), I am still falling > down on my very > first reported bug, namely this local ktok program. > I still, after > all that you've done, find that it dies on an > illegal instruction > on the Macintosh (I am running 10.3 on a Powerbook). > > The problem goes away if I use either @M3nogc or > @M3noincremental. > The gdb backtrace is not very helpful: it says the > program is > crashing somewhere in a text processing module, > creating an iterator > on a sorted table. > > Sorry to do this but I am feeling a bit clueless, so > if you're > interested and have the time to look into it, I have > set up a minimal > test here: > > http://www.async.caltech.edu/~mika/ktok_example.tgz > > Unfortunately, ktok itself depends on a bunch of > packages. > > To build this, set your CM3 environment variable to > anything (1 > works) and just "make" (GNU make, please). Set the > DEBUGLEVEL > environment variable to "10" for a bit more output > (not much). The > very last step (compiling package cit_parse) fails > for me... > Specifically, the step is: > > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", > line 20: quake runtime error: exit 4: > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > > Looking a bit closer: > > [lapdog:~/t/cit_parse/src] mika% gdb > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri > Jul 16 21:42:28 GMT 2004) > Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 > Starting program: > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > Reading symbols for shared libraries . done > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > > Program received signal EXC_BAD_INSTRUCTION, Illegal > instruction/operand. > 0x00b111c8 in ?? () > (gdb) where > #0 0x00b111c8 in ?? () > #1 0x000120e4 in TextSubs__Apply > (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at > TextSubs.m3:64 > #2 0x0005b15c in RTLinker__RunMainBody > (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 > #3 0x00059f20 in RTLinker__AddUnitI > (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 > #4 0x0005a01c in RTLinker__AddUnit > (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 > #5 0x00001ecc in main (argc=4, argv=0xbffffadc, > envp=0xbffffaf0) at _m3main.mc:4 > (gdb) > > Also: > > PROCEDURE Apply(self: T; src: TEXT): TEXT = > VAR > wr := TextWr.New(); > c: CHAR; > ind, pos, lastFlushed: INTEGER := 0; > textLen := Text.Length(src); > iter: SortedTextTextTbl.Iterator; > original, replacement: TEXT; > key, prefix: TEXT; > PROCEDURE Flush() = > BEGIN > Wr.PutText(wr, Text.Sub(src, lastFlushed, pos > - lastFlushed)); > END Flush; > BEGIN > WHILE pos < textLen DO > c := Text.GetChar(src, pos); > IF c IN self.starts THEN > Debug.Out("analysing: " & Text.Sub(src, > pos), 100); > iter := self.tbl.iterateOrdered(); (* line > 64 *) > ind := pos; > original := ""; > REPEAT > INC(ind); > ... > > I am mystified as to why gdb would say that > RTLinker__RunMainBody > would be calling TextSubs__Apply. > > With @M3nogc or @M3noincremental, all is well... > > I will see if I can figure out more, but this > problem just doesn't > seem to want to go away. To the best of my > knowledge, ktok doesn't > use any UNSAFE code (outside of whatever's in libm3 > of course). > > Mika > > 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 > === message truncated === ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome From dabenavidesd at yahoo.es Wed Jul 4 23:40:34 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 Jul 2007 23:40:34 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Message-ID: <20070704214034.90770.qmail@web27105.mail.ukl.yahoo.com> Sorry the last message was too long and I think was cutted by the mailer. Hi: I take the sources from the your web page and type make on the top of the directory v and end in this message: ===> cit_parse --- building in LINUXLIBC6 --- ignoring override("cit_parse", "/home/danielb/Desktop/v") /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x4000b19f *** "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 1536: /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 --procedure-- -line- -file--- exec -- _exec 20 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _xCons 37 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tCons 81 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tConsUn 82 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl Token 85 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl include_dir 3 /home/danielb/Desktop/v/cit_parse/src/m3makefile 5 /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args Fatal Error: package build failed Well that was because of the lack of the file PRS.t Searching I noticed that the file is in v/cit_parse/src/PRS.t and made a copy on v/parserlib/ktok/src directory Then try make again and but this time, get this: cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e new source -> compiling PRSTok.m3 "../LINUXLIBC6/PRSTok.m3", line 1: syntax error: missing INTERFACE or MODULE keyword "../LINUXLIBC6/PRSTok.m3", line 1: unable to find interface () "../LINUXLIBC6/PRSTok.m3", line 1: warning: file name (PRSTok.m3) doesn't match module name () 2 errors and 1 warning encountered new source -> compiling PRSTok.i3 new source -> compiling PRSLex.i3 new source -> compiling PRSLex.m3 new source -> compiling PRSParse.i3 new source -> compiling PRSParse.m3 new source -> compiling PRSLexStd.i3 new source -> compiling PRSLexStd.m3 new source -> compiling PRSParseStd.i3 new source -> compiling PRSParseStd.m3 new source -> compiling CHPTok.i3 new source -> compiling CHPTok.m3 "../LINUXLIBC6/CHPTok.m3", line 36: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered new source -> compiling CHPLex.i3 new source -> compiling CHPLex.m3 new source -> compiling CHPParse.i3 new source -> compiling CHPParse.m3 new source -> compiling CHPLexStd.i3 new source -> compiling CHPLexStd.m3 new exporters -> recompiling PRSTok.i3 compilation failed => not building library "libcit_parse.a" Fatal Error: package build failed danielb at danielb-desktop:~/code/caltech-parser/v2/v$ It seems PRSTok.m3 does exist on v/cit_parse/LINUXLIBC6 but is an empty file. Maybe Im not doing the right steps? Thanks --- "Daniel Alejandro Benavides D." escribi?: > Hi: > I take the sources from the your web page and type > make on the top of the directory v and end in this > message: > > ===> cit_parse > --- building in LINUXLIBC6 --- > > ignoring override("cit_parse", > "/home/danielb/Desktop/v") > > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to > dereference NIL > *** pc = 0x4000b19f > *** > > "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", > line 20: quake runtime error: exit 1536: > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 20 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _xCons 37 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _tCons 81 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _tConsUn 82 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > Token 85 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > include_dir 3 > /home/danielb/Desktop/v/cit_parse/src/m3makefile > 5 > /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > > Well that was because of the lack of the file PRS.t > > Searching I noticed that the file is in > v/cit_parse/src/PRS.t and made a copy on > v/parserlib/ktok/src directory > Then try make again and but this time, get this: > > cp > /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome From mika at async.caltech.edu Thu Jul 5 14:48:46 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 05 Jul 2007 05:48:46 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Wed, 04 Jul 2007 23:35:13 +0200." <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Message-ID: <200707051248.l65Cmk7b064556@camembert.async.caltech.edu> Hi Daniel, Thanks for helping look into this. Could you send me a gdb stack trace or something along those lines of the segmentation violation? It doesn't have to be m3gdb, normal gdb would do fine. The PRS.t file isn't missing. What you're seeing is ktok being run with a CWD of /home/danielb/Desktop/v/cit_parse/LINUXLIBC6 , so PRS.t is indeed "../src/PRS.t". The reason the file is empty in the last example is that that's what had been generated by the time the ktok program crashed. That's exactly what I get on my Mac, except the program crashes on an illegal instruction, not a segfault. Of course it works fine on PM3, both Windows and Unix, and older versions of CM3... I'm sure there's some kind of bug in ktok, too. Mika "Daniel Alejandro Benavides D." writes: >Hi: >I take the sources from the your web page and type >make on the top of the directory v and end in this >message: > >===> cit_parse >--- building in LINUXLIBC6 --- > >ignoring override("cit_parse", >"/home/danielb/Desktop/v") > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to >dereference NIL >*** pc = 0x4000b19f >*** > >"/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", >line 20: quake runtime error: exit 1536: >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 > >--procedure-- -line- -file--- >exec -- >_exec 20 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_xCons 37 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_tCons 81 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_tConsUn 82 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >Token 85 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >include_dir 3 >/home/danielb/Desktop/v/cit_parse/src/m3makefile > 5 >/home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > >Fatal Error: package build failed > >Well that was because of the lack of the file PRS.t > >Searching I noticed that the file is in >v/cit_parse/src/PRS.t and made a copy on >v/parserlib/ktok/src directory >Then try make again and but this time, get this: > >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y >. >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext >../src/CHPLexStd.e >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext >../src/CHPLexStd.e >new source -> compiling PRSTok.m3 >"../LINUXLIBC6/PRSTok.m3", line 1: syntax error: >missing INTERFACE or MODULE keyword >"../LINUXLIBC6/PRSTok.m3", line 1: unable to find >interface () >"../LINUXLIBC6/PRSTok.m3", line 1: warning: file name >(PRSTok.m3) doesn't match module name () >2 errors and 1 warning encountered >new source -> compiling PRSTok.i3 >new source -> compiling PRSLex.i3 >new source -> compiling PRSLex.m3 >new source -> compiling PRSParse.i3 >new source -> compiling PRSParse.m3 >new source -> compiling PRSLexStd.i3 >new source -> compiling PRSLexStd.m3 >new source -> compiling PRSParseStd.i3 >new source -> compiling PRSParseStd.m3 >new source -> compiling CHPTok.i3 >new source -> compiling CHPTok.m3 >"../LINUXLIBC6/CHPTok.m3", line 36: warning: >potentially unhandled exception: >RTAllocator.OutOfMemory >1 warning encountered >new source -> compiling CHPLex.i3 >new source -> compiling CHPLex.m3 >new source -> compiling CHPParse.i3 >new source -> compiling CHPParse.m3 >new source -> compiling CHPLexStd.i3 >new source -> compiling CHPLexStd.m3 >new exporters -> recompiling PRSTok.i3 >compilation failed => not building library >"libcit_parse.a" >Fatal Error: package build failed > >danielb at danielb-desktop:~/code/caltech-parser/v2/v$ > > >It seems PRSTok.m3 does exist on >v/cit_parse/LINUXLIBC6 but is an empty file. > >Maybe Im not doing the right steps? > >Thanks > > > > >--- Mika Nystrom wrote: > >> Hi again! >> >> I was able to boot the CVS head of CM3 on my Mac >> just fine now, >> using the cm3.cfg you sent me. I am still running >> the old OS >> (Panther, is it?) so I tried doing it the hard way >> instead of using >> your binaries, and I got something that works pretty >> well. Mentor >> and Juno work, at least, and that's usually a good >> indicator that >> one is on the right track... >> >> But (of course there's a "but"), I am still falling >> down on my very >> first reported bug, namely this local ktok program. >> I still, after >> all that you've done, find that it dies on an >> illegal instruction >> on the Macintosh (I am running 10.3 on a Powerbook). >> >> The problem goes away if I use either @M3nogc or >> @M3noincremental. >> The gdb backtrace is not very helpful: it says the >> program is >> crashing somewhere in a text processing module, >> creating an iterator >> on a sorted table. >> >> Sorry to do this but I am feeling a bit clueless, so >> if you're >> interested and have the time to look into it, I have >> set up a minimal >> test here: >> >> http://www.async.caltech.edu/~mika/ktok_example.tgz >> >> Unfortunately, ktok itself depends on a bunch of >> packages. >> >> To build this, set your CM3 environment variable to >> anything (1 >> works) and just "make" (GNU make, please). Set the >> DEBUGLEVEL >> environment variable to "10" for a bit more output >> (not much). The >> very last step (compiling package cit_parse) fails >> for me... >> Specifically, the step is: >> >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> WELCOME! >> GOT TOKPARAMS! >> GOT TOKENS >> GOT SUBS! >> "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", >> line 20: quake runtime error: exit 4: >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> >> Looking a bit closer: >> >> [lapdog:~/t/cit_parse/src] mika% gdb >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri >> Jul 16 21:42:28 GMT 2004) >> Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 >> Starting program: >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> Reading symbols for shared libraries . done >> WELCOME! >> GOT TOKPARAMS! >> GOT TOKENS >> GOT SUBS! >> >> Program received signal EXC_BAD_INSTRUCTION, Illegal >> instruction/operand. >> 0x00b111c8 in ?? () >> (gdb) where >> #0 0x00b111c8 in ?? () >> #1 0x000120e4 in TextSubs__Apply >> (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at >> TextSubs.m3:64 >> #2 0x0005b15c in RTLinker__RunMainBody >> (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 >> #3 0x00059f20 in RTLinker__AddUnitI >> (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 >> #4 0x0005a01c in RTLinker__AddUnit >> (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 >> #5 0x00001ecc in main (argc=4, argv=0xbffffadc, >> envp=0xbffffaf0) at _m3main.mc:4 >> (gdb) >> >> Also: >> >> PROCEDURE Apply(self: T; src: TEXT): TEXT = >> VAR >> wr := TextWr.New(); >> c: CHAR; >> ind, pos, lastFlushed: INTEGER := 0; >> textLen := Text.Length(src); >> iter: SortedTextTextTbl.Iterator; >> original, replacement: TEXT; >> key, prefix: TEXT; >> PROCEDURE Flush() = >> BEGIN >> Wr.PutText(wr, Text.Sub(src, lastFlushed, pos >> - lastFlushed)); >> END Flush; >> BEGIN >> WHILE pos < textLen DO >> c := Text.GetChar(src, pos); >> IF c IN self.starts THEN >> Debug.Out("analysing: " & Text.Sub(src, >> pos), 100); >> iter := self.tbl.iterateOrdered(); (* line >> 64 *) >> ind := pos; >> original := ""; >> REPEAT >> INC(ind); >> ... >> >> I am mystified as to why gdb would say that >> RTLinker__RunMainBody >> would be calling TextSubs__Apply. >> >> With @M3nogc or @M3noincremental, all is well... >> >> I will see if I can figure out more, but this >> problem just doesn't >> seem to want to go away. To the best of my >> knowledge, ktok doesn't >> use any UNSAFE code (outside of whatever's in libm3 >> of course). >> >> Mika >> >> 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 >> >=== message truncated === > > > > >____________________________________________________________________________________ >?Descubre una nueva forma de obtener respuestas a tus preguntas! >Entra en Yahoo! Respuestas. >http://es.answers.yahoo.com/info/welcome From rodney.bates at wichita.edu Thu Jul 5 15:35:31 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 05 Jul 2007 08:35:31 -0500 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468CF3A3.2090707@wichita.edu> Could you make your replacement setjmp/longjmp available for those of us who are still maintaining old PM3 implementations? This would be a great help. Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Thu Jul 5 20:46:21 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 5 Jul 2007 20:46:21 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707051248.l65Cmk7b064556@camembert.async.caltech.edu> Message-ID: <20070705184621.73160.qmail@web27113.mail.ukl.yahoo.com> Hi Mika: What I get here executing is sometimes an Illegal intruction or Floating point exception (I guess OS message when executing the program) or the CM3 runtime error message. Well I debugged a time and I got it breaks inside RTType.m3, but m3gdb process ends, besides the tok process. (m3gdb) where #0 FindType (id=995871772) at RTType.m3:137 #1 0x0809afb6 in ScanTypecase (ref=16_b7eeb0cc, x=16_0815d844) at RTType.m3:123 #2 0x080b2bdf in Sub (t=16_b7eeb0cc, start=0, length=10) at TextSub.m3:35 #3 0x0804a6ba in Base (t=16_b7eeb0cc, suffix=16_081397a8) at TokParams.m3:22 #4 0x0804a700 in SetBaseFrom (t=16_b7eeb0cc, suffix=16_081397a8) at TokParams.m3:40 #5 0x0804ab74 in Get (progName=16_08139798, inSuffix=16_081397a8, outSuffix=16_081397b8, specifyTok=FALSE, _result= RECORD source = NIL; out = NIL; tokSource = NIL; tokOut = NIL; outBase = NIL; tokOutBase = NIL; END) at TokParams.m3:63 #6 0x08049011 in Main (mode=1) at Main.m3:92 #7 0x080949d9 in RunMainBody (m=16_081504e0) at RTLinker.m3:399 #8 0x0809347e in AddUnitI (m=16_081504e0) at RTLinker.m3:113 #9 0x08093507 in AddUnit (b={"Main_M3", Declared at: Main.m3:90}) at RTLinker.m3:122 #10 0x08048217 in main (argc=4, argv=0xbf921b64, envp=0xbf921b78) at _m3main.mc:4 (m3gdb) step FindType (id=4) at RTType.m3:138 138 in RTType.m3 (m3gdb) step Segmentation fault danielb at danielb-desktop:~/code/caltech-parser/v/cit_parse/LINUXLIBC6$ *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xb7eef1e7 *** danielb at danielb-desktop:~/code/caltech-parser/v/cit_parse/LINUXLIBC6$ Any more helpful? Bye --- Mika Nystrom wrote: > Hi Daniel, > > Thanks for helping look into this. Could you send > me a gdb stack > trace or something along those lines of the > segmentation violation? > It doesn't have to be m3gdb, normal gdb would do > fine. > > The PRS.t file isn't missing. What you're seeing is > ktok being run > with a CWD of > /home/danielb/Desktop/v/cit_parse/LINUXLIBC6 , so > PRS.t is indeed "../src/PRS.t". > > The reason the file is empty in the last example is > that that's > what had been generated by the time the ktok program > crashed. That's > exactly what I get on my Mac, except the program > crashes on an > illegal instruction, not a segfault. Of course it > works fine on > PM3, both Windows and Unix, and older versions of > CM3... I'm sure > there's some kind of bug in ktok, too. > > Mika > > > > "Daniel Alejandro Benavides D." writes: > >Hi: > >I take the sources from the your web page and type > >make on the top of the directory v and end in this > >message: > > > >===> cit_parse > >--- building in LINUXLIBC6 --- > > > >ignoring override("cit_parse", > >"/home/danielb/Desktop/v") > > > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > > > > > >*** > >*** runtime error: > >*** Segmentation violation - possible attempt to > >dereference NIL > >*** pc = 0x4000b19f > >*** > > > >"/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", > >line 20: quake runtime error: exit 1536: > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > > > >--procedure-- -line- -file--- > >exec -- > >_exec 20 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_xCons 37 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_tCons 81 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_tConsUn 82 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >Token 85 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >include_dir 3 > >/home/danielb/Desktop/v/cit_parse/src/m3makefile > > 5 > >/home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > > > >Fatal Error: package build failed > > > >Well that was because of the lack of the file PRS.t > > > >Searching I noticed that the file is in > >v/cit_parse/src/PRS.t and made a copy on > >v/parserlib/ktok/src directory > >Then try make again and but this time, get this: > > > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y > >. > >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext > >../src/CHPLexStd.e > >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext > >../src/CHPLexStd.e > >new source -> compiling PRSTok.m3 > >"../LINUXLIBC6/PRSTok.m3", line 1: syntax error: > >missing INTERFACE or MODULE keyword > >"../LINUXLIBC6/PRSTok.m3", line 1: unable to find > >interface () > >"../LINUXLIBC6/PRSTok.m3", line 1: warning: file > name > >(PRSTok.m3) doesn't match module name ( id>) > >2 errors and 1 warning encountered > >new source -> compiling PRSTok.i3 > >new source -> compiling PRSLex.i3 > >new source -> compiling PRSLex.m3 > >new source -> compiling PRSParse.i3 > >new source -> compiling PRSParse.m3 > >new source -> compiling PRSLexStd.i3 > >new source -> compiling PRSLexStd.m3 > >new source -> compiling PRSParseStd.i3 > >new source -> compiling PRSParseStd.m3 > >new source -> compiling CHPTok.i3 > >new source -> compiling CHPTok.m3 > >"../LINUXLIBC6/CHPTok.m3", line 36: warning: > >potentially unhandled exception: > >RTAllocator.OutOfMemory > >1 warning encountered > >new source -> compiling CHPLex.i3 > >new source -> compiling CHPLex.m3 > >new source -> compiling CHPParse.i3 > >new source -> compiling CHPParse.m3 > >new source -> compiling CHPLexStd.i3 > >new source -> compiling CHPLexStd.m3 > >new exporters -> recompiling PRSTok.i3 > >compilation failed => not building library > >"libcit_parse.a" > >Fatal Error: package build failed > > > >danielb at danielb-desktop:~/code/caltech-parser/v2/v$ > > > > > > >It seems PRSTok.m3 does exist on > >v/cit_parse/LINUXLIBC6 but is an empty file. > > > >Maybe Im not doing the right steps? > > > >Thanks > > > > > > > > > >--- Mika Nystrom wrote: > > > >> Hi again! > >> > >> I was able to boot the CVS head of CM3 on my Mac > >> just fine now, > >> using the cm3.cfg you sent me. I am still > running > >> the old OS > >> (Panther, is it?) so I tried doing it the hard > way > >> instead of using > >> your binaries, and I got something that works > pretty > >> well. Mentor > >> and Juno work, at least, and that's usually a > good > >> indicator that > >> one is on the right track... > >> > >> But (of course there's a "but"), I am still > falling > >> down on my very > >> first reported bug, namely this local ktok > program. > >> I still, after > >> all that you've done, find that it dies on an > >> illegal instruction > >> on the Macintosh (I am running 10.3 on a > Powerbook). > >> > >> The problem goes away if I use either @M3nogc or > >> @M3noincremental. > >> The gdb backtrace is not very helpful: it says > the > >> program is > >> crashing somewhere in a text processing module, > >> creating an iterator > >> on a sorted table. > >> > >> Sorry to do this but I am feeling a bit clueless, > so > === message truncated === ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From dragisha at m3w.org Tue Jul 10 22:46:40 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 10 Jul 2007 22:46:40 +0200 Subject: [M3devel] revevrsed EXTERNAL, almotht :) Message-ID: <1184100400.29933.3.camel@faramir.m3w.org> Can I make Modula-3 procedure, or even better - Main_M3 to be called other than that in object code? -- Dragi?a Duri? From lemming at henning-thielemann.de Wed Jul 11 13:49:34 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Jul 2007 13:49:34 +0200 (MEST) Subject: [M3devel] revevrsed EXTERNAL, almotht :) In-Reply-To: <1184100400.29933.3.camel@faramir.m3w.org> References: <1184100400.29933.3.camel@faramir.m3w.org> Message-ID: On Tue, 10 Jul 2007, [UTF-8] Dragi??a Duri?^G wrote: > Can I make Modula-3 procedure, or even better - Main_M3 to be called > other than that in object code? Do you mean the CALLBACK pragma? From dragisha at m3w.org Wed Jul 11 18:02:34 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 11 Jul 2007 18:02:34 +0200 Subject: [M3devel] revevrsed EXTERNAL, almotht :) In-Reply-To: References: <1184100400.29933.3.camel@faramir.m3w.org> Message-ID: <1184169754.2424.4.camel@faramir.m3w.org> I think not. What I need for Modula-3 program to be loaded (ie initialized) as a .so is true C procedure entry point, trivial to write in C so there is no need to force CM3 to make one of Modula-3 procedures known by "external" name. Standard _m3main execution flow has to be split in two parts and executed from this C "stub". Calling conventions are possible another problem. I don't think there would be one under *nix, and for Windows - it's a todo :). On Wed, 2007-07-11 at 13:49 +0200, Henning Thielemann wrote: > On Tue, 10 Jul 2007, [UTF-8] Dragi?a Duri^G wrote: > > > Can I make Modula-3 procedure, or even better - Main_M3 to be called > > other than that in object code? > > Do you mean the CALLBACK pragma? -- Dragi?a Duri? From wagner at elegosoft.com Fri Jul 13 09:33:58 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jul 2007 09:33:58 +0200 (CEST) Subject: [M3devel] http://llvm.org/ as M3 backend; was: Re: Why? In-Reply-To: <12678.1184263773@sa.vix.com> References: <0W2kg.46558$4L1.20223@newssvr11.news.prodigy.com> <87mzcft02e.fsf@thalassa.informatimago.com> <4foappF1k1snbU1@individual.net> <4gde82F1lsi14U1@individual.net> <4gh9gfF1neuiuU1@individual.net> <4grqp3F1obofbU1@individual.net> <12678.1184263773@sa.vix.com> Message-ID: <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> On Thu, July 12, 2007 20:09, Paul Vixie wrote: > has anyone investigated http://llvm.org/ as a potential new M3 backend? I don't think so, but the first paragraphs on the front page sound promising. I'll cc this to the m3devel list to see if anybody knows more or is interested. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Jul 13 17:43:01 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 13 Jul 2007 10:43:01 -0500 Subject: [M3devel] CVS deprecated info strings? Message-ID: <46979D85.3060001@wichita.edu> I just got this message from CVS: cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. I am guessing this refers to stylized comments in the file(s) I committed. Any pointers to documentation on what CVS really wants here? The files are all part of m3gdb, and no doubt contain things from very long ago. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jdp at polstra.com Fri Jul 13 17:51:31 2007 From: jdp at polstra.com (John Polstra) Date: Fri, 13 Jul 2007 08:51:31 -0700 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <46979F83.4070301@polstra.com> Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts > to use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. > Any pointers to documentation on what CVS really wants here? The files are > all part of m3gdb, and no doubt contain things from very long ago. I'm just guessing, but this sounds more like a complaint from the perl scripts in the repository's CVSROOT directory. Maybe somebody updated the perl installation on the repository host, deprecating some feature that the scripts use. John From hosking at cs.purdue.edu Fri Jul 13 18:05:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 13 Jul 2007 12:05:28 -0400 Subject: [M3devel] http://llvm.org/ as M3 backend; was: Re: Why? In-Reply-To: <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> References: <0W2kg.46558$4L1.20223@newssvr11.news.prodigy.com> <87mzcft02e.fsf@thalassa.informatimago.com> <4foappF1k1snbU1@individual.net> <4gde82F1lsi14U1@individual.net> <4gh9gfF1neuiuU1@individual.net> <4grqp3F1obofbU1@individual.net> <12678.1184263773@sa.vix.com> <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> Message-ID: <099535B8-2C0A-4345-BF35-CBA02EC75F2C@cs.purdue.edu> I've had a little contact with some of the llvm team re M3, but forget now who that was. Certainly, I think it would be fun to do an M3CG->LLVM backend. On Jul 13, 2007, at 3:33 AM, Olaf Wagner wrote: > On Thu, July 12, 2007 20:09, Paul Vixie wrote: >> has anyone investigated http://llvm.org/ as a potential new M3 >> backend? > > I don't think so, but the first paragraphs on the front page sound > promising. I'll cc this to the m3devel list to see if anybody knows > more or is interested. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 > Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From stsp at elego.de Fri Jul 13 18:15:15 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 13 Jul 2007 18:15:15 +0200 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <20070713161515.GC98227@ted.stsp.lan> On Fri, Jul 13, 2007 at 10:43:01AM -0500, Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts to > use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. No. It's a known issue. > Any pointers to documentation on what CVS really wants here? http://ximbiot.com/cvs/manual/cvs-1.12.6/cvs_18.html#SEC168 -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mika at async.caltech.edu Mon Jul 16 03:53:11 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 18:53:11 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Mon, 02 Jul 2007 11:03:42 EDT." Message-ID: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> 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! 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 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? From hosking at cs.purdue.edu Mon Jul 16 05:39:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Jul 2007 23:39:26 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> References: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> Message-ID: <9E796D22-3940-4FB8-9B5B-F17D4648DF56@cs.purdue.edu> 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! > > 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"))); Where does the variable 'wr' come from? It is this 'wr' that is failing the assert. It should not be gray, assuming that the GC was able to find it. Can I see your Main.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 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? From hosking at cs.purdue.edu Mon Jul 16 05:41:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Jul 2007 23:41:31 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> References: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> Message-ID: 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 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? From mika at async.caltech.edu Mon Jul 16 05:51:33 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 20:51:33 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Sun, 15 Jul 2007 23:39:26 EDT." <9E796D22-3940-4FB8-9B5B-F17D4648DF56@cs.purdue.edu> Message-ID: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> Tony Hosking writes: ... >> >> Line 113 in Main.m3 is: >> >> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); > >Where does the variable 'wr' come from? It is this 'wr' that is >failing the assert. It should not be gray, assuming that the GC was >able to find it. Can I see your Main.m3? > It fails exactly the same way with @M3paranoidgc. wr comes from FileWr.Open. The programmer has re-used wr for two open FileWrs... I marked line 113, where it crashes: (* Copyright (c) 2000 California Institute of Technology *) (* All rights reserved. See the file COPYRIGHT for a full description. *) (* $Id: Main.m3,v 1.3 2002/12/11 08:54:53 kp Exp $ *) MODULE Main; IMPORT Debug; IMPORT tokformBundle, Bundle; IMPORT TokParams; IMPORT TokSpec; IMPORT FileWr, Wr, Thread, OSError; IMPORT TextWr; IMPORT TextSubs; IMPORT TextList; IMPORT Pathname; IMPORT Fmt; IMPORT FmtTable; (* IMPORT Term; *) <* FATAL Thread.Alerted, Wr.Failure *> VAR Form := tokformBundle.Get(); PROCEDURE FormatTypes(t: TextList.T; tokName, kind: TEXT): TEXT = VAR wr := TextWr.New(); cur := t; subs: TextSubs.T; BEGIN WHILE cur # NIL DO subs := NEW(TextSubs.T).init(); subs.add("%type", cur.head); subs.add("%tok", tokName); Wr.PutText(wr, subs.apply(Bundle.Get(Form, kind))); cur := cur.tail; END; RETURN TextWr.ToText(wr); END FormatTypes; PROCEDURE FormatLegalConst(tok: TokSpec.T): TEXT = VAR dummy: TEXT; fmt := NEW(FmtTable.T).init(); BEGIN FOR i := 1 TO tok.lastConstCode DO IF tok.constTokensR.get(i, dummy) THEN fmt.putInt(i); END; END; RETURN fmt.toText(); END FormatLegalConst; PROCEDURE FormatNamedConst(tok: TokSpec.T): TEXT = VAR cur := tok.tokens; name: TEXT; code: INTEGER; wr := TextWr.New(); BEGIN WHILE cur # NIL DO name := cur.head; IF tok.constTokens.get(name, code) THEN Wr.PutText(wr, " " & name & " = " & Fmt.Int(code) & ";\n"); END; cur := cur.tail; END; RETURN TextWr.ToText(wr); END FormatNamedConst; PROCEDURE Subs(tok: TokSpec.T; name: TEXT): TextSubs.T = VAR subs := NEW(TextSubs.T).init(); BEGIN subs.add("\\\n", ""); subs.add("%tok", name); subs.add("%type", FormatTypes(tok.varTokens, name, "tokform.type")); subs.add("%case", FormatTypes(tok.varTokens, name, "tokform.case")); subs.add("%constSet", FormatLegalConst(tok)); subs.add("%constName", FormatNamedConst(tok)); subs.add("%lastConst", Fmt.Int(tok.lastConstCode)); subs.add("%gen", "(* Generated by ktok *)"); RETURN subs; END Subs; VAR tp: TokParams.T; tok: TokSpec.T; subs: TextSubs.T; wr: Wr.T; BEGIN Debug.S("WELCOME!"); tp := TokParams.Get("tok", ".t", "Tok.i3", FALSE); Debug.S("GOT TOKPARAMS!"); tok := TokParams.ReadTokens(tp); Debug.S("GOT TOKENS"); subs := Subs(tok, tp.outBase); Debug.S("GOT SUBS!"); TRY wr := FileWr.Open(tp.out); EXCEPT OSError.E => Debug.Error("Cannot open tok interface output file: " & tp.out); END; Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.i3"))); Wr.Close(wr); TRY wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3")); EXCEPT OSError.E => Debug.Error("Cannot open tok implementation output file: " & Pathname.ReplaceExt(tp.out, "m3")); END; Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); (* line 113 *) Wr.Close(wr); END Main. From mika at async.caltech.edu Mon Jul 16 06:50:52 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 21:50:52 -0700 Subject: [M3devel] User-level threading In-Reply-To: Your message of "Wed, 04 Jul 2007 22:25:16 +0200." <20070704202516.GA26977@elegosoft.com> Message-ID: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Olaf Wagner writes: >On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: >> In looking at things again, I am more and more convinced that >> ThreadPosix should be implemented against the standard API for >> makecontext/getcontext/setcontext/swapcontext. Platforms that do not >> provide these will need to provide an equivalent implementation of >> these routines, similar to what you suggest. Right now, I know all of >> SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary >> support. > >I think a `standard' implementation using makecontext/getcontext/... >would be the best. For those platforms that do not support that, >we can still use a C or assembler implementation. > >I would strongly vote for keeping user-level threading, too. Wouldn't the ideal be to have a mixed system, where N user-level threads run inside M <= N, M \approx NCPUS Pthreads? Anyone who thinks user-level threads are unnecessary should try the following program, which runs just fine under user-level threads on FreeBSD, and locks up horrendously after running about 4% of the way on Darwin/Pthreads... Mika MODULE Main; IMPORT Thread; IMPORT Rd, Stdio, Wr, Random, Fmt; TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; PROCEDURE A(cl : Cl) : REFANY = VAR rand := NEW(Random.Default).init(); BEGIN LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText(Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END END A; CONST Nthreads=10000; BEGIN FOR i := 1 TO Nthreads DO Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush(Stdio.stdout); EVAL Thread.Fork(NEW(Cl)) END; LOOP WITH c = Rd.GetChar(Stdio.stdin) DO IF c = 'q' THEN EXIT END END END END Main. > >Olaf >-- >Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 >http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Mon Jul 16 08:27:36 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 23:27:36 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Sun, 15 Jul 2007 23:41:31 EDT." Message-ID: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 16 14:42:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:42:43 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> References: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> Message-ID: <4612CAB0-02E4-4D53-AF6F-B05C1972296E@cs.purdue.edu> I'll need to run this in the debugger. Do your previous instructions for download and build still hold true? On Jul 15, 2007, at 11:51 PM, Mika Nystrom wrote: > Tony Hosking writes: > ... >>> >>> Line 113 in Main.m3 is: >>> >>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); >> >> Where does the variable 'wr' come from? It is this 'wr' that is >> failing the assert. It should not be gray, assuming that the GC was >> able to find it. Can I see your Main.m3? >> > > It fails exactly the same way with @M3paranoidgc. > > wr comes from FileWr.Open. The programmer has re-used wr for two > open FileWrs... I marked line 113, where it crashes: > > (* Copyright (c) 2000 California Institute of Technology *) > (* All rights reserved. See the file COPYRIGHT for a full > description. *) > (* $Id: Main.m3,v 1.3 2002/12/11 08:54:53 kp Exp $ *) > > MODULE Main; > IMPORT Debug; > IMPORT tokformBundle, Bundle; > IMPORT TokParams; > IMPORT TokSpec; > IMPORT FileWr, Wr, Thread, OSError; > IMPORT TextWr; > IMPORT TextSubs; > IMPORT TextList; > IMPORT Pathname; > IMPORT Fmt; > IMPORT FmtTable; > (* IMPORT Term; *) > <* FATAL Thread.Alerted, Wr.Failure *> > > VAR > Form := tokformBundle.Get(); > > PROCEDURE FormatTypes(t: TextList.T; tokName, kind: TEXT): TEXT = > VAR > wr := TextWr.New(); > cur := t; > subs: TextSubs.T; > BEGIN > WHILE cur # NIL DO > subs := NEW(TextSubs.T).init(); > subs.add("%type", cur.head); > subs.add("%tok", tokName); > Wr.PutText(wr, subs.apply(Bundle.Get(Form, kind))); > cur := cur.tail; > END; > RETURN TextWr.ToText(wr); > END FormatTypes; > > PROCEDURE FormatLegalConst(tok: TokSpec.T): TEXT = > VAR > dummy: TEXT; > fmt := NEW(FmtTable.T).init(); > BEGIN > FOR i := 1 TO tok.lastConstCode DO > IF tok.constTokensR.get(i, dummy) THEN > fmt.putInt(i); > END; > END; > RETURN fmt.toText(); > END FormatLegalConst; > > PROCEDURE FormatNamedConst(tok: TokSpec.T): TEXT = > VAR > cur := tok.tokens; > name: TEXT; > code: INTEGER; > wr := TextWr.New(); > BEGIN > WHILE cur # NIL DO > name := cur.head; > IF tok.constTokens.get(name, code) THEN > Wr.PutText(wr, " " & name & " = " & Fmt.Int(code) & ";\n"); > END; > cur := cur.tail; > END; > RETURN TextWr.ToText(wr); > END FormatNamedConst; > > PROCEDURE Subs(tok: TokSpec.T; name: TEXT): TextSubs.T = > VAR > subs := NEW(TextSubs.T).init(); > BEGIN > subs.add("\\\n", ""); > subs.add("%tok", name); > subs.add("%type", FormatTypes(tok.varTokens, name, > "tokform.type")); > subs.add("%case", FormatTypes(tok.varTokens, name, > "tokform.case")); > subs.add("%constSet", FormatLegalConst(tok)); > subs.add("%constName", FormatNamedConst(tok)); > subs.add("%lastConst", Fmt.Int(tok.lastConstCode)); > subs.add("%gen", "(* Generated by ktok *)"); > RETURN subs; > END Subs; > > > VAR > tp: TokParams.T; > tok: TokSpec.T; > subs: TextSubs.T; > wr: Wr.T; > BEGIN > Debug.S("WELCOME!"); > tp := TokParams.Get("tok", ".t", "Tok.i3", FALSE); > Debug.S("GOT TOKPARAMS!"); > tok := TokParams.ReadTokens(tp); > Debug.S("GOT TOKENS"); > subs := Subs(tok, tp.outBase); > Debug.S("GOT SUBS!"); > TRY > wr := FileWr.Open(tp.out); > EXCEPT OSError.E => > Debug.Error("Cannot open tok interface output file: " & tp.out); > END; > > Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.i3"))); > Wr.Close(wr); > > TRY > wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3")); > EXCEPT OSError.E => > Debug.Error("Cannot open tok implementation output file: " & > Pathname.ReplaceExt(tp.out, "m3")); > END; > Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); (* > line 113 *) > Wr.Close(wr); > END Main. > From hosking at cs.purdue.edu Mon Jul 16 14:47:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:47:08 -0400 Subject: [M3devel] User-level threading In-Reply-To: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> References: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Message-ID: <319398F1-B01D-4E75-BBDA-AD31D9E951D4@cs.purdue.edu> Mixed systems are difficult to get working properly (because of interactions between system and user scheduling), and usually result in more trouble than they are worth (witness discussions on this subject regarding Jikes RVM). The difficulties are particularly pronounced with preemptive scheduling where system thread switches can occur at any time. My inclination is to implement the user-level threading properly using setcontext, etc., instead of setjmp/ longjmp. I will probably get to this next on my list of tinkering tasks with CM3. Right now, I want to finish off my LONGINT implementation (grappling with the compiler as we speak) as well as the GC issue you reported. On Jul 16, 2007, at 12:50 AM, Mika Nystrom wrote: > Olaf Wagner writes: >> On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: >>> In looking at things again, I am more and more convinced that >>> ThreadPosix should be implemented against the standard API for >>> makecontext/getcontext/setcontext/swapcontext. Platforms that do >>> not >>> provide these will need to provide an equivalent implementation of >>> these routines, similar to what you suggest. Right now, I know >>> all of >>> SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary >>> support. >> >> I think a `standard' implementation using makecontext/getcontext/... >> would be the best. For those platforms that do not support that, >> we can still use a C or assembler implementation. >> >> I would strongly vote for keeping user-level threading, too. > > Wouldn't the ideal be to have a mixed system, where N user-level > threads > run inside M <= N, M \approx NCPUS Pthreads? > > Anyone who thinks user-level threads are unnecessary should try the > following program, which runs just fine under user-level threads > on FreeBSD, and locks up horrendously after running about 4% of the > way on Darwin/Pthreads... > > Mika > > MODULE Main; > IMPORT Thread; > IMPORT Rd, Stdio, Wr, Random, Fmt; > > TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; > > > PROCEDURE A(cl : Cl) : REFANY = > VAR rand := NEW(Random.Default).init(); > BEGIN > LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText > (Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END > END A; > > CONST Nthreads=10000; > BEGIN > FOR i := 1 TO Nthreads DO > Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush > (Stdio.stdout); > EVAL Thread.Fork(NEW(Cl)) > END; > > LOOP > WITH c = Rd.GetChar(Stdio.stdin) DO > IF c = 'q' THEN EXIT END > END > END > END Main. > >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 >> Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 >> 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >> Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 From hosking at cs.purdue.edu Mon Jul 16 14:51:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:51:06 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: On Jul 16, 2007, at 2:27 AM, Mika Nystrom wrote: > An update: > > I was able to get everything to build by using @M3noincremental. Yes, this makes sense, since the error is one that can only occur with incremental GC. > > I am still running into a few errors when trying to run things. > So far, most problems seem to be traceable back to a garbage > collection > problem. @M3noincremental helps, but doesn't solve all GC-related > issues. > > The errors I seem to be running into are... > > 1. Some kind of memory protection error when I am reading pickles > from files. Haven't looked at this in detail yet. Odd. Please fill me in. > 2. The assert when spawning threads in mentor, mentioned earlier. I've not seen this since the fix I made a few weeks ago. It was related to weak references. > 3. Various sinks of processor time when running multithreaded things. > > The program I sent earlier to illustrate the (in)efficiency of > threading was an attempt to isolate some of the issues under 3., but > that simple program didn't seem to tickle any bugs. Instead, I have > an Othello program that does. It uses Trestle, X, etc., and you can > get it (via the references on the Wikipedia m3 page, actually: it > was originally part of an assignment for a class I was teaching at > Caltech). Cool. Another bug to chase. > What happens is this... everything seems functionally correct, but > after a while, the program, for no apparent reason at all, starts > to take 100% of the CPU. I think there may be several bugs. I have > been able to get programs to slow down and threads to stop running. I'd appreciate any hints you can give. What platform? Possibly related to thread stopping/restarting. > To the description: my othello program opens up a VBT and calls a > Thread.Join. This puts it in ThreadPThread.InnerWait, and there > all seems OK. The running thread (or one of them) calls Trestle.Ping, > which calls Thread.Pause. For a few seconds all is OK, the mouse > pointer is tracked, repaints work, etc. But after a while, the > program goes haywire. What happens is that the program is still > functionally correct, as before, but it starts to eat 100% CPU. > Looking a little closer, Thread.Pause has died, or is at least badly > wounded. It simply doesn't yield the CPU. > > I changed ThreadPThread.Pause to the following: > > PROCEDURE Pause(n: LONGREAL) = > VAR > amount, remaining: Utime.struct_timespec; > self := Self(); > BEGIN > IF self = NIL THEN Die(ThisLine(), "Pause called from a non- > Modula-3 thread") END; > IF n <= 0.0d0 THEN RETURN END; > IF perfOn THEN PerfChanged(self.id, State.pausing) END; > ToNTime(n, amount); > <* ASSERT amount.tv_sec >= 0 *> > > RTIO.PutChar('f'); RTIO.Flush(); > LOOP > RTIO.PutChar('b'); RTIO.Flush(); > <* ASSERT amount.tv_sec >= 0 *> (* line 756 *) > RTIO.PutChar('a'); RTIO.Flush(); > WITH nr = Utime.nanosleep(amount, remaining) DO > IF nr = 0 THEN > RTIO.PutChar('!'); RTIO.Flush(); > EXIT > ELSE > RTIO.PutChar('.'); RTIO.Flush(); > VAR > as := amount.tv_sec; > an := amount.tv_nsec; > rs := remaining.tv_sec; > rn := remaining.tv_nsec; > BEGIN > amount := remaining; > END > END > END > END; > IF perfOn THEN PerfChanged(self.id, State.alive) END; > END Pause; > > Ironically, the change seems to make the program slightly > less susceptible to trouble, but it still happens. The end result of > running my program is not terribly helpful: > > Repaint! > .ba.b > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 756 > *** That doesn't mesh with the latest version of ThreadPThread.m3. Are you sure you are up to date? > > > Program exited with code 01. > (gdb) where > No stack. > > Note that line 756 is after the arguments to nanosleep have already > been checked. The tv_secs gets set to -1... and nanosleep returns > right away. But nanosleep declares its first argument as const *, > so it's not nanosleep itself that's clobbering it. > > XXX > XXX The problem goes away with @M3nogc. This problem does NOT > XXX go away with @M3noincremental! > XXX > > (And @M3paranoidgc doesn't seem to be any more paranoid than the > usual one.) > > Maybe this is a stupid question... why are Pause and AlertPause > implemented with different system calls? (Note that I had another > program that was exhibiting the same type of processor greed, and > changing all occurrences of Pause to AlertPause in that program > didn't seem to cure it.) > > I think mentor and Juno show the 100% CPU symptoms as well. Yes, > I just re-ran mentor and I got the same assertion failing. > > ---- > > One last issue: there is indeed one more problem. @M3nogc does > solve the cpu utilization and Utime problems. It does not, however, > solve the protection bug (#1 above). Something's up, because Network > Objects do work fine, but reading and writing certain things to > disk does not appear to work (and those pickles were written by the > same executable as the one that tried to read them). All these > programs work reliably under PM3 on both FreeBSD and Windows > 2000/cygwin (not that I am suggesting that they are bug free). > > Mika > > > Tony Hosking writes: >> >> On Jul 15, 2007, at 9:53 PM, Mika Nystrom wrote: >> >>> Hello there, >>> >>> I am now back to trying to get my system compiled under CM3. Not >>> to pick on CM3 or anything, but my old PM3s still have no trouble >>> with it! >> >> PS Old PM3s don't have the new compiler-driven incremental >> collection scheme, so you will hopefully gain fromm moving to CM3 so >> long as we can fix your problem. I should be able to diagnose this >> without too much trouble. Any chance you can run with the >> @M3paranoidgc flag passed to tok? >> >>> >>> I'm back to staring at the following: >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 2310 >>> *** >>> >>> Here's how I got it: I ran the "tok" program from my example on one >>> of the example files (not sure if this is part of the distributed >>> "caltech-parser" or not). The revision of RTCollector.m3 is 1.29. >>> >>> I spoke to the author of "tok" last week (who now programs in a >>> kind of bastardized C++ with Modula-3 keywords and a garbage >>> collector), and he said this program actually does very little work. >>> It's just an interface generator that makes interfaces to declare >>> a few constants. Why it seems to have so much trouble running is >>> a mystery to me. >>> >>> traceback: >>> >>> (gdb) where >>> #0 0x9004308c in kill () >>> #1 0x9009fb3c in abort () >>> #2 0x00096f48 in RTOS__Crash () at RTOS.m3:20 >>> #3 0x0005bcd8 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at >>> RTProcess.m3:65 >>> #4 0x0008e4d8 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at >>> RTError.m3:115 >>> #5 0x0008e084 in RTError__MsgS (M3_AJWxb1_file=0xc6420, >>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0xca418, >>> M3_Bd56fi_msgB=0xcbed8, M3_Bd56fi_msgC=0xca418) at RTError.m3:40 >>> #6 0x0008eb80 in RTException__Crash (M3_Cblw37_a=0xbfffee20, >>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0xcb580) at RTException.m3:79 >>> #7 0x0008e744 in RTException__DefaultBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:39 >>> #8 0x0008e60c in RTException__InvokeBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:25 >>> #9 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at >>> RTExFrame.m3:29 >>> #10 0x0008e838 in RTException__DefaultBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:47 >>> #11 0x0008e60c in RTException__InvokeBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:25 >>> #12 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at >>> RTExFrame.m3:29 >>> #13 0x00079738 in RTHooks__ReportFault (M3_AJWxb1_module=0xb3ec0, >>> M3_AcxOUs_info=73920) at RTHooks.m3:110 >>> #14 0x0006ff44 in _m3_fault (M3_AcxOUs_arg=73920) >>> #15 0x0006bcec in RTHooks__CheckStoreTraced >>> (M3_Af40ku_ref=0xb24368) at RTCollector.m3:2310 >>> #16 0x000700dc in ThreadPThread__InnerLockMutex >>> (M3_AYIbX3_m=0xb24368, M3_BXP32l_self=0xb244b0) at >>> ThreadPThread.m3:126 >>> #17 0x000704d0 in ThreadPThread__LockMutex (M3_AYIbX3_m=0xb24368) >>> at ThreadPThread.m3:153 >>> #18 0x00019abc in Wr__PutText (M3_BxxOH1_wr=0xb24368, >>> M3_Bd56fi_t=0xb403d4) at Wr.m3:93 >>> #19 0x00003e94 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113 >>> #20 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at >>> RTLinker.m3:399 >>> #21 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at >>> RTLinker.m3:113 >>> #22 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at >>> RTLinker.m3:122 >>> #23 0x00001ecc in main (argc=4, argv=0xbffffb30, envp=0xbffffb44) >>> at _m3main.mc:4 >>> (gdb) >>> >>> Line 113 in Main.m3 is: >>> >>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); >>> >>> (Bundle is made by m3bundle) >>> >>> OS: >>> Darwin lapdog.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> This is a CM3 checkout from yesterday, built cleanly according to >>> your instructions (starting with an absolutely clean system and >>> bootstrapped using binary version 5.4.0). I managed to screw it >>> up at one point but I ran do-cm3-std realclean and do-cm3-core >>> realclean several times. >>> >>> But isn't this the bug you already fixed? I just don't see how I >>> could possibly be getting an old RTCollector.m3 file in my system. >>> I cleaned it obsessively while I was building it. >>> >>> I am using the cfg file you sent me, too. (I copied it in, in place >>> of the 5.4.0 default cfg.) You can see I am using pthreads. >>> >>> @M3noincremental and @M3nogc work, as usual. >>> >>> ---------- >>> >>> I saw another problem. I was running mentor, the packet routing >>> animation, and hit an assertion in ThreadPThread.m3. >>> >>> >>> [lapdog:~] mika% mentor >>> >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 673 >>> *** >>> >>> Abort >>> >>> WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*> >>> END; >>> WITH r = Upthread.attr_init(attr) DO <*ASSERT r=0*> END; >>> WITH r = Upthread.attr_getstacksize(attr, bytes) DO >>> <*ASSERT r=0*> END; >>> bytes := MAX(bytes, size * ADRSIZE(Word.T)); >>> WITH r = Upthread.attr_setstacksize(attr, bytes) DO >>> <*ASSERT r=0*> END; (* line 673 *) >>> WITH r = Upthread.create(act.handle, attr, ThreadBase, >>> act) DO >>> <*ASSERT r=0*> >>> END; >>> act.next := allThreads; >>> act.prev := allThreads.prev; >>> act.size := size; >>> allThreads.prev.next := act; >>> allThreads.prev := act; >>> WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*> >>> END; >>> END; >>> >>> Is it trying to make too many threads? Is there a practical limit >>> on the number of threads under pthreads? (The code I am eventually >>> going to want to build will want to make hundreds and possibly >>> thousands of concurrently executing threads, which I don't think >>> is a problem with ThreadPosix, and I'll be pretty disappointed if >>> that turns out to be a problem with pthreads...well I suppose I can >>> always go back to user-level threads.) >>> >>> Mika >>> >>> >>> Tony Hosking writes: >>>> Sigh, this is a knock-on bug that manifests as a result of the >>>> supposed "fix" I made in response to your previous post. As it >>>> turns >>>> out, the user-level threads code has some badness built in with >>>> respect to incremental GC. I need to rework the user-level >>>> threading >>>> code to totally eliminate use of traced references in the code for >>>> ProcessStacks. The ring of threads needs to be maintained in an >>>> untraced data structure for the newer GC code to work properly. >>>> This >>>> is something that is very carefully done in the pthreads-based >>>> system- >>>> level threading that is used on all the platforms I typically >>>> maintain locally (SOLgnu/SOLsun, LINUXLIBC6, I386_DARWIN, >>>> PPC_DARWIN), so I haven't seen this problem so extensively. You >>>> are >>>> correct that running without incremental collection (using >>>> @M3noincremental) will avoid the problem until I am able to come up >>>> with a fix. >>>> >>>> On Jul 2, 2007, at 6:35 AM, Mika Nystrom wrote: >>>> >>>>> Ok, things are certainly better on FreeBSD/i386 now. I just spent >>>>> a few minutes playing a newly compiled tetris. >>>>> >>>>> However, I still get that very first error I wrote about: >>>>> >>>>> /home/mika/u/parserlib/ktok/FreeBSD4/tok ../src/Lang.t -o >>>>> LangTok.i3 >>>>> WELCOME! >>>>> GOT TOKPARAMS! >>>>> GOT TOKENS >>>>> GOT SUBS! >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** <*ASSERT*> failed. >>>>> *** file "../src/runtime/common/RTCollector.m3", line 2310 >>>>> *** >>>>> >>>>> What I did was... I wasn't sure exactly what state my CM3 was in, >>>>> as usual, so I deleted all of /usr/local/cm3, plus my repository >>>>> checkout, checked it out from scratch, and followed your bootstrap >>>>> instructions of June 24 to the letter, except that where you said >>>>> to do "do-cm3-std.sh realclean" I did "do-cm3-core.sh realclean" >>>>> and then "do-cm3-std.sh realclean", built the stage 1 and stage 2, >>>>> installed the new compiler. No problems until trying to run >>>>> this code, which is part of our local version of the "caltech- >>>>> parser"... >>>>> Here we go: >>>>> >>>>> >>>>> Program received signal SIGABRT, Aborted. >>>>> 0x68b5e0c7 in kill () from /lib/libc.so.5 >>>>> (gdb) where >>>>> #0 0x68b5e0c7 in kill () from /lib/libc.so.5 >>>>> #1 0x68b5312e in raise () from /lib/libc.so.5 >>>>> #2 0x68bc6cef in abort () from /lib/libc.so.5 >>>>> #3 0x682bc7f2 in RTOS__Crash () at RTOS.m3:20 >>>>> #4 0x682b3b66 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at >>>>> RTProcess.m3:65 >>>>> #5 0x682b1e30 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at >>>>> RTError.m3:115 >>>>> #6 0x682b1b71 in RTError__MsgS (M3_AJWxb1_file=0x682dd4c8, >>>>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0x682df048, >>>>> M3_Bd56fi_msgB=0x682d9630, M3_Bd56fi_msgC=0x682df048) at >>>>> RTError.m3:40 >>>>> #7 0x682b21f4 in RTException__Crash (M3_Cblw37_a=0xbfbfe0b8, >>>>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x682d94e0) at >>>>> RTException.m3:79 >>>>> #8 0x682b1f58 in RTException__DefaultBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:39 >>>>> #9 0x682b1ebc in RTException__InvokeBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:25 >>>>> #10 0x682bdc37 in RTException__Raise (M3_Cblw37_act=0xbfbfe0b8) at >>>>> RTExFrame.m3:29 >>>>> #11 0x682b1ff8 in RTException__DefaultBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:47 >>>>> #12 0x682b1ebc in RTException__InvokeBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:25 >>>>> #13 0x682bdc37 in RTException__Raise (M3_Cblw37_act=0xbfbfe0b8) at >>>>> RTExFrame.m3:29 >>>>> #14 0x6829da9e in RTHooks__ReportFault >>>>> (M3_AJWxb1_module=0x682dd640, M3_AcxOUs_info=73920) at >>>>> RTHooks.m3:110 >>>>> #15 0x682afc48 in _m3_fault (M3_AcxOUs_arg=73920) from /usr/local/ >>>>> cm3/pkg/m3core/FreeBSD4/libm3core.so.5 >>>>> #16 0x682ad065 in RTHooks__CheckStoreTraced >>>>> (M3_Af40ku_ref=0x68c2b104) at RTCollector.m3:2310 >>>>> #17 0x682bfba2 in ThreadPosix__LockMutex (M3_AYIbX3_m=0x68c2b104) >>>>> at ThreadPosix.m3:416 >>>>> #18 0x681ab817 in Wr__PutText (M3_BxxOH1_wr=0x68c2b104, >>>>> M3_Bd56fi_t=0x68c05608) at Wr.m3:93 >>>>> #19 0x0804a445 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113 >>>>> #20 0x682b120a in RTLinker__RunMainBody (M3_DjPxE3_m=0x804cae0) at >>>>> RTLinker.m3:399 >>>>> #21 0x682b0735 in RTLinker__AddUnitI (M3_DjPxE3_m=0x804cae0) at >>>>> RTLinker.m3:113 >>>>> #22 0x682b07bc in RTLinker__AddUnit (M3_DjPxE5_b=0x8049e50) at >>>>> RTLinker.m3:122 >>>>> #23 0x080491f5 in main (argc=4, argv=0xbfbfe40c, envp=0xbfbfe420) >>>>> at _m3main.mc:4 >>>>> (gdb) >>>>> >>>>> 2302 PROCEDURE CheckStoreTraced (ref: REFANY) = >>>>> 2303 VAR p := Word.RightShift (LOOPHOLE(ref, Word.T), >>>>> LogBytesPerPage); >>>>> 2304 BEGIN >>>>> 2305 RTOS.LockHeap (); >>>>> 2306 INC(checkStoreTraced); >>>>> 2307 >>>>> 2308 WITH h = HeaderOf (LOOPHOLE(ref, RefReferent)) DO >>>>> 2309 <*ASSERT h.typecode # RT0.TextLitTypecode*> >>>>> 2310 <*ASSERT NOT h.gray*> >>>>> 2311 >>>>> 2312 IF h.dirty THEN >>>>> 2313 <*ASSERT NOT desc[p - p0].clean*> >>>>> 2314 ELSE >>>>> 2315 h.dirty := TRUE; >>>>> 2316 IF desc[p - p0].clean THEN >>>>> 2317 desc[p - p0].clean := FALSE; >>>>> 2318 IF perfOn THEN PerfChange(p, PageCount(p)); END; >>>>> 2319 END; >>>>> 2320 END; >>>>> 2321 END; >>>>> 2322 >>>>> 2323 RTOS.UnlockHeap(); >>>>> 2324 RETURN; >>>>> 2325 END CheckStoreTraced; >>>>> >>>>> I believe this is the same as the first bug I ran across. The >>>>> program >>>>> (ktok) does appear to work fine with @M3nogc. >>>>> >>>>> Further information: I am also "able" to get mentor and Juno to >>>>> crash on this line 2310. I checked the bootstrapping process by >>>>> building a third-stage bootstrapped compiler, and it was byte-for- >>>>> byte >>>>> identical to the second-stage bootstrap. Finally, I am still a >>>>> bit >>>>> worried about libraries (maybe across the different booting >>>>> stages) >>>>> getting polluted: I am able to run Juno, mentor, etc., except for >>>>> the garbage-collection problem, but my own Trestle applications >>>>> crash somewhere in the (C) X libraries, even though they have >>>>> worked >>>>> fine on several other versions of Modula-3. (Most likely, of >>>>> course, >>>>> it's some sort of bug of mine... generally I am not in the >>>>> habit of >>>>> blaming the libraries or compiler, but you never know!) >>>>> >>>>> The line-2310 crashes also seem to go away with @M3noincremental, >>>>> by the >>>>> way. >>>>> >>>>> >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>>> I've just checked in a fix to ThreadPosix.m3 that eliminates your >>>>>> problem with user-level threads. I have tested this on >>>>>> I386_DARWIN >>>>>> and it appears to be working just fine now. Please try again >>>>>> with >>>>>> the updated ThreadPosix.m3. >>>>>> >>>>>> On Jun 25, 2007, at 3:05 PM, Mika Nystrom wrote: >>>>>> >>>>>>> Indeed, -g was one of the culprits. I changed it to -gstabs+ >>>>>>> and >>>>>>> got a bit further... (please scroll down to STEP 2, sorry) >>>>>>> >>>>>>> Tony Hosking writes: >>>>>>>> Sounds like we really need some work done in this area. I very >>>>>>>> rarely use the build scripts, since I bootstrap manually >>>>>>>> from old >>>>>>>> compilers to new compilers rather than use the scripts. I >>>>>>>> suggest >>>>>>>> the following approach, which I hope you will try, and then >>>>>>>> report >>>>>>>> back on. >>>>>>>> >>>>>>>> Install the bootstrap compiler as you did originally: >>>>>>>> >>>>>>>>> rm -rf /usr/local/cm3/* >>>>>>>>> >>>>>>>>> cd ~/cm3-cvs >>>>>>>>> mkdir boot >>>>>>>>> cd boot >>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz >>>>>>>>> ./cminstall >>>>>>>> >>>>>>>> Now you will have some kind of cm3 installed, presumably in / >>>>>>>> usr/ >>>>>>>> local/cm3/bin/cm3. >>>>>>>> >>>>>>>> Make sure you have a fresh CVS checkout in directory cm3 (let's >>>>>>>> assume this is in your home directory ~/cm3). Also, make sure >>>>>>>> you >>>>>>>> have an up-to-date version of the CM3 backend compiler cm3cg >>>>>>>> installed by executing the following: >>>>>>>> >>>>>>>> STEP 0: >>>>>>>> >>>>>>>> export CM3=/usr/local/cm3/bin/cm3 >>>>>>>> cd ~/cm3/m3-sys/m3cc >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> >>>>>>>> You can skip this last step if you know your backend compiler >>>>>>>> is up >>>>>>>> to date. >>>>>>>> >>>>>>>> Now, let's build the new compiler from scratch (this is the >>>>>>>> sequence >>>>>>>> I use regularly to test changes to the run-time system >>>>>>>> whenever I >>>>>>>> make them): >>>>>>>> >>>>>>>> STEP 1: >>>>>>>> >>>>>>>> cd ~/cm3/m3-libs/m3core >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-libs/libm3 >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3middle >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3linker >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3front >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3quake >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/cm3 >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> >>>>>>>> At this point you should have a bootstrapped version of cm3 >>>>>>>> installed >>>>>>>> in the directory /usr/local/cm3/pkg/cm3/TARGET/cm3 (where >>>>>>>> TARGET is >>>>>>>> the CM3 target platform you are building on -- e.g., >>>>>>>> LINUXLIBC6, >>>>>>>> PPC_DARWIN, ...). Note that this did not overwrite your >>>>>>>> original >>>>>>>> installed compiler in /usr/local/cm3/bin/cm3. We >>>>>>>> are now going to test the new compiler, which was built using >>>>>>>> the old >>>>>>>> compiler, by bootstrapping it one more time. >>>>>>>> >>>>>>>> From here on out, please replace TARGET with your target >>>>>>>> platform as >>>>>>>> appropriate. >>>>>>>> >>>>>>>> STEP 2: >>>>>>>> >>>>>>>> export CM3=/usr/local/cm3/pkg/cm3/TARGET/cm3 >>>>>>>> cd ~/cm3/scripts >>>>>>>> ./do-cm3-std.sh realclean >>>>>>>> REPEAT STEP 1 to rebuild the libraries and the compiler >>>>>>>> using the >>>>>>>> STEP 1 bootstrap compiler. >>>>>>>> >>>>>>>> Now you have a STEP 2 bootstrap compiler installed in /usr/ >>>>>>>> local/ >>>>>>>> cm3/ >>>>>>>> pkg/cm3/TARGET/cm3. Let's assume the new compiler now works >>>>>>>> properly >>>>>>>> since it successfully bootstrapped itself, but to be sure we >>>>>>>> can >>>>>>>> now >>>>>>>> use it to rebuild the world: >>>>>>> >>>>>>> Ok, I got this far. I built the step 1 (m3core...cm3), set my >>>>>>> compiler to the newly-built compiler, and rebuilt >>>>>>> (m3core...cm3). >>>>>>> No errors anywhere, beautiful. >>>>>>> >>>>>>>> >>>>>>>> cd ~/cm3/scripts >>>>>>>> ./do-cm3-std.sh realclean >>>>>>>> ./do-cm3-std.sh buildship >>>>>>> >>>>>>> Here's where it dies: >>>>>>> >>>>>>> ./do-cm3-std.sh buildship >>>>>>> CM3C = >>>>>>> /big/home2/mika/2/cm3-cvs/fresh/cm3/scripts/pkgmap.sh -c "/usr/ >>>>>>> local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/home2/ >>>>>>> mika/2/ >>>>>>> cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 - >>>>>>> ship - >>>>>>> DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' " m3core libm3 >>>>>>> patternmatching m3middle m3quake m3scanner m3tools m3cgcat >>>>>>> m3cggen >>>>>>> m3gdb m3bundle arithmetic bitvector digraph parseparams >>>>>>> realgeometry set slisp sortedtableextras table-list tempfiles >>>>>>> tcp >>>>>>> udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO >>>>>>> commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser >>>>>>> cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr >>>>>>> sharedobj sharedobjgen odbc postgres95 db smalldb stable >>>>>>> stablegen >>>>>>> X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps >>>>>>> formsvbt formsview formsedit codeview mg mgkit opengl anim3D >>>>>>> zeus >>>>>>> m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq >>>>>>> obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd >>>>>>> obliqsrvui obliqbinmin obliqbinstd obliqbin! >>>>>>> ui obliqbinanim visualobliq vocgi voquery vorun webvbt >>>>>>> recordheap >>>>>>> rehearsecode replayheap showheap shownew showthread pkl-fonts >>>>>>> juno- >>>>>>> machine juno-compiler juno-app cube calculator fisheye mentor >>>>>>> === package /big/home2/mika/2/cm3-cvs/fresh/cm3/m3-libs/ >>>>>>> m3core === >>>>>>> +++ /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/ >>>>>>> home2/ >>>>>>> mika/2/cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/ >>>>>>> cm3 - >>>>>>> ship -DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' +++ >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>> >>>>>>> Abort trap >>>>>>> *** execution of failed *** >>>>>>> >>>>>>> This time it appears to be cm3 itself that's crashing: >>>>>>> >>>>>>> (310)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>$CM3 -keep - >>>>>>> commands >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> Abort >>>>>>> >>>>>>> What follows is what m3gdb has to say about this. I take it >>>>>>> that >>>>>>> the last error message comes from my -gstabs+ option. m3gdb >>>>>>> doesn't >>>>>>> like this new binary: it can't print variables and sometimes >>>>>>> crashes >>>>>>> trying. Would I have better luck with "-gstabs", do you >>>>>>> think? Or >>>>>>> do I just need to fix the compile process and install a new >>>>>>> m3gdb? >>>>>>> (I take it there is a newer one: mine is very old. But I >>>>>>> remember >>>>>>> that m3gdb doesn't always work that well...) >>>>>>> >>>>>>> Mika >>>>>>> >>>>>>> #1 16_81a619d in __raise () >>>>>>> #2 16_81a3b8f in abort () >>>>>>> #3 16_8178d16 in RTOS.Crash () at RTOS.m3:20 >>>>>>> #4 16_8171fd2 in RTProcess.Crash (msg=NIL) at RTProcess.m3:65 >>>>>>> #5 16_8170428 in RTError.EndError (crash=TRUE) at >>>>>>> RTError.m3:115 >>>>>>> #6 16_8170169 in RTError.MsgS (file=16_820a508, line=690, >>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at >>>>>>> RTError.m3:40 >>>>>>> #7 16_81707ec in RTException.Crash (a=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79 >>>>>>> #8 16_8170550 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39 >>>>>>> #9 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #10 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #11 16_81705f0 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47 >>>>>>> #12 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #13 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #14 16_8160bba in RTHooks.ReportFault (module=16_820a680, >>>>>>> info=22080) at RTHooks.m3:110 >>>>>>> #15 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0 >>>>>>> #16 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> #17 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3300) at >>>>>>> RTCollector.m3:2296 >>>>>>> #18 16_814400c in Stdio.ShutDown () at Stdio.m3:43 >>>>>>> #19 16_8171f51 in RTProcess.InvokeExitors () at RTProcess.m3:40 >>>>>>> #20 16_8171fc5 in RTProcess.Crash (msg=NIL) at RTProcess.m3:61 >>>>>>> #21 16_8170428 in RTError.EndError (crash=TRUE) at >>>>>>> RTError.m3:115 >>>>>>> #22 16_8170169 in RTError.MsgS (file=16_820a508, line=690, >>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at >>>>>>> RTError.m3:40 >>>>>>> #23 16_81707ec in RTException.Crash (a=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79 >>>>>>> #24 16_8170550 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39 >>>>>>> #25 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #26 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #27 16_81705f0 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47 >>>>>>> #28 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #29 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #30 16_8160bba in RTHooks.ReportFault (module=16_820a680, >>>>>>> info=22080) at RTHooks.m3:110 >>>>>>> #31 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0 >>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3004) at >>>>>>> RTCollector.m3:2296 >>>>>>> #34 16_817c41e in ThreadF.ProcessStacks (p=16_816415e) at >>>>>>> ThreadPosix.m3:522 >>>>>>> #35 16_8165213 in RTCollector.CollectSomeInStateZero () at >>>>>>> RTCollector.m3:845 >>>>>>> #36 16_8164d2c in RTCollector.CollectSome () at >>>>>>> RTCollector.m3:741 >>>>>>> #37 16_816487b in RTCollector.CollectEnough () at >>>>>>> RTCollector.m3:659 >>>>>>> #38 16_81673cd in RTHeapRep.AllocTraced (def=16_81f8f38, >>>>>>> dataSize=8200, dataAlignment=4, initProc=16_bfbfe0f4, >>>>>>> pool=RECORD >>>>>>> desc = RECORD space = Current; generation = Younger; pure = >>>>>>> FALSE; >>>>>>> note = Allocated; gray = FALSE; clean = FALSE; continued = >>>>>>> FALSE; link = 0; END; notAfter = {Copied}; page = 0; stack = 0; >>>>>>> next = NIL; limit = NIL; busy = FALSE; END) >>>>>>> at RTCollector.m3:1417 >>>>>>> #39 16_816218e in RTAllocator.GetOpenArray (def=16_81f8f38, s= >>>>>>> [2048]) at RTAllocator.m3:308 >>>>>>> #40 16_8161737 in RTHooks.AllocateOpenArray (defn=16_81f8f38, s= >>>>>>> [2048]) at RTAllocator.m3:156 >>>>>>> #41 16_8129d56 in M3ID_M3 (mode=1) at M3ID.m3:40 >>>>>>> #42 16_816f802 in RTLinker.RunMainBody (m=16_81f8cc0) at >>>>>>> RTLinker.m3:399 >>>>>>> #43 16_816f6ca in RTLinker.RunMainBody (m=16_81c0880) at >>>>>>> RTLinker.m3:379 >>>>>>> #44 16_816f6ca in RTLinker.RunMainBody (m=16_81c06a0) at >>>>>>> RTLinker.m3:379 >>>>>>> #45 16_816f6ca in RTLinker.RunMainBody (m=16_81bc920) at >>>>>>> RTLinker.m3:379 >>>>>>> #46 16_816ed2d in RTLinker.AddUnitI (m=16_81bc920) at >>>>>>> RTLinker.m3:113 >>>>>>> #47 16_816edb4 in RTLinker.AddUnit (b=16_8065527) at >>>>>>> RTLinker.m3:122 >>>>>>> module "_m3main": missing debug info for global data >>>>>>> >>>>>>> (gdb) up 32 >>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> RTCollector.m3:690: No such file or directory. >>>>>>> (gdb) >>>>>>> Suspended >>>>>>> (360)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>find ../.. -name >>>>>>> RTCollector.m3 >>>>>>> ../../m3-libs/m3core/src/runtime/common/RTCollector.m3 >>>>>>> (361)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>fg >>>>>>> m3gdb /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 >>>>>>> (gdb) dir ../../m3-libs/m3core/src/runtime/common/ >>>>>>> Source directories searched: /big/home2/mika/2/cm3-cvs/fresh/ >>>>>>> cm3/m3- >>>>>>> libs/m3core/../../m3-libs/m3core/src/runtime/common:$cdir:$cwd >>>>>>> (gdb) list >>>>>>> 685 VAR timeOnEntry, timeOnExit: Time.T; (* time of >>>>>>> collector entry/exit *) >>>>>>> 686 >>>>>>> 687 PROCEDURE CollectorOn () = >>>>>>> 688 (* LL >= RTOS.LockHeap *) >>>>>>> 689 BEGIN >>>>>>> 690 <* ASSERT NOT collectorOn *> >>>>>>> 691 collectorOn := TRUE; >>>>>>> 692 >>>>>>> 693 IF incremental AND NOT RTLinker.incremental >>>>>>> 694 OR generational AND NOT RTLinker.generational THEN >>>>>>> (gdb) print collectorOn >>>>>>> can't find identifier: collectorOn >>>>>>> (gdb) up >>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3004) at >>>>>>> RTCollector.m3:2296 >>>>>>> 2296 CollectorOn(); >>>>>>> (gdb) print collectorOn >>>>>>> can't find identifier: collectorOn >>>>>>> (gdb) print ref >>>>>>> Segmentation fault >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Assuming this succeeded then we can be pretty sure /usr/local/ >>>>>>>> cm3/ >>>>>>>> pkg/ >>>>>>>> cm3/TARGET/cm3 is good, so we can make it our default >>>>>>>> compiler by >>>>>>>> replacing the original /usr/local/cm3/bin/cm3: >>>>>>>> >>>>>>>> cp $CM3 /usr/local/cm3/bin/cm3 >>>>>>>> >>>>>>>> On Jun 23, 2007, at 2:38 PM, Mika Nystrom wrote: >>>>>>>> >>>>>>>>> Ok, I'm sorry if I seem a bit dimwitted in the morning like >>>>>>>>> this, >>>>>>>>> but how exactly does one get started? I wish there were a >>>>>>>>> file >>>>>>>>> called >>>>>>>>> "GETTING_STARTED" or something like that in scripts... >>>>>>>>> >>>>>>>>> My Mac is very slow so I switched to my FreeBSD/i386 system >>>>>>>>> (which has >>>>>>>>> PM3 happily installed on it) and tried to install CM3 from >>>>>>>>> scratch. >>>>>>>>> Here are the exact commands I typed. >>>>>>>>> >>>>>>>>> >>>>>>>>> rm -rf /usr/local/cm3/* >>>>>>>>> >>>>>>>>> cd ~/cm3-cvs >>>>>>>>> mkdir boot >>>>>>>>> cd boot >>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz >>>>>>>>> ./cminstall >>>>>>>>> >>>>>>>>> # now I seem to have some kind of cm3 installed, /usr/local/ >>>>>>>>> cm3/ >>>>>>>>> bin/ >>>>>>>>> cm3 >>>>>>>>> >>>>>>>>> cd cm3 # location of my CM3 checkout >>>>>>>>> cvs update -d . >>>>>>>>> >>>>>>>>> cd scripts >>>>>>>>> ./boot-cm3-with-m3.sh realclean >>>>>>>>> ./do-cm3-std.sh realclean >>>>>>>>> >>>>>>>>> ./upgrade.sh # fails here, libm3 not >>>>>>>>> compiled >>>>>>>>> ./boot-cm3-with-m3.sh build # builds cm3, but fails on >>>>>>>>> cminstall, patternmatching not built >>>>>>>>> >>>>>>>>> ./do-cm3-std.sh build # OK >>>>>>>>> ./do-cm3-std.sh buildship # OK >>>>>>>>> >>>>>>>>> ./boot-cm3-with-m3.sh realclean # start over >>>>>>>>> ./boot-cm3-with-m3.sh build # OK >>>>>>>>> ./boot-cm3-with-m3.sh buildship # OK >>>>>>>>> >>>>>>>>> ./do-cm3-std.sh realclean # OK >>>>>>>>> ./do-cm3-std.sh build # dies miserably... maybe >>>>>>>>> the >>>>>>>>> compiler can't handle the new libraries? >>>>>>>>> >>>>>>>>> ./install-cm3-compiler.sh upgrade # OK, new cm3 binary >>>>>>>>> installed >>>>>>>>> >>>>>>>>> After all that, "game over." I have a cm3 that segfaults. >>>>>>>>> >>>>>>>>> Text.i3: In function 'Text_I3': >>>>>>>>> Text.i3:81: internal compiler error: Segmentation fault >>>>>>>>> Please submit a full bug report, >>>>>>>>> with preprocessed source if appropriate. >>>>>>>>> See 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? From hosking at cs.purdue.edu Mon Jul 16 18:32:25 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:32:25 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: Again, please confirm that you are using the CVS head. 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 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? From hosking at cs.purdue.edu Mon Jul 16 18:47:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:47:06 -0400 Subject: [M3devel] User-level threading In-Reply-To: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> References: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Message-ID: <4E226F4D-9281-4FBA-9306-591A39ED64CC@cs.purdue.edu> This runs fine for me on Darwin pthreads up until it fails trying to create a new pthread after 6982 threads: the call to pthread_create returns an error code. I am assuming the error is due to hitting some system limit. On Jul 16, 2007, at 12:50 AM, Mika Nystrom wrote: > MODULE Main; > IMPORT Thread; > IMPORT Rd, Stdio, Wr, Random, Fmt; > > TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; > > > PROCEDURE A(cl : Cl) : REFANY = > VAR rand := NEW(Random.Default).init(); > BEGIN > LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText > (Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END > END A; > > CONST Nthreads=10000; > BEGIN > FOR i := 1 TO Nthreads DO > Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush > (Stdio.stdout); > EVAL Thread.Fork(NEW(Cl)) > END; > > LOOP > WITH c = Rd.GetChar(Stdio.stdin) DO > IF c = 'q' THEN EXIT END > END > END > END Main. From hosking at cs.purdue.edu Mon Jul 16 18:57:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:57:28 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: 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 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? From mika at async.caltech.edu Mon Jul 16 21:33:53 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 16 Jul 2007 12:33:53 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Mon, 16 Jul 2007 12:57:28 EDT." Message-ID: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Tue Jul 17 00:53:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 18:53:49 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> References: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> Message-ID: <31544177-4CC1-42C6-8306-DF3AD5BC5775@cs.purdue.edu> 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 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? From mika at async.caltech.edu Tue Jul 17 09:31:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 17 Jul 2007 00:31:44 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Mon, 16 Jul 2007 18:53:49 EDT." <31544177-4CC1-42C6-8306-DF3AD5BC5775@cs.purdue.edu> Message-ID: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> 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=, M3_CVvbAZ_session=0x1f93290, M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=) 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=, M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Tue Jul 17 16:34:53 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Jul 2007 10:34:53 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> References: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> Message-ID: Good. I'll try to digest your report more deeply before getting back. Generally, try running with @M3noincremental @M3nogenerational to run with simple GC but without the bells and whistles. You can add @M3paranoidgc to be particularly careful. That way, at least we know that you are getting the benefit of GC without major complications. 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=, M3_CVvbAZ_session=0x1f93290, > M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', > M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid= 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=, > M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Thu Jul 19 05:53:38 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 18 Jul 2007 23:53:38 -0400 Subject: [M3devel] LONGINT Message-ID: I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. From wagner at elegosoft.com Thu Jul 19 08:23:50 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Jul 2007 08:23:50 +0200 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <20070719062350.GA12517@elegosoft.com> On Wed, Jul 18, 2007 at 11:53:38PM -0400, Tony Hosking wrote: > I've successfully bootstrapped a CM3 compiler that supports LONGINT > as a 64-bit integer type (equivalent to "long long" in C) in addition > to INTEGER (same as "long" in C). This will be useful for > simplifying interfaces to C library routines that expect to be able > to treat 64-bit integers such as "off_t" for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type > (I'm not sure this would ever be a good idea) so it cannot be used to > index arrays, define enumerations etc., though the simple operations > ABS, MAX, MIN, addition, comparisons, MOD, multiplication, > subtraction, assignment, are all supported. This includes changes to > m3core (with support for Long.T similar to Word.T, plus RTTipe and > RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, > m3front, and the gcc-based compiler backend. There is still work > that needs to be done to support and test all the other M3 tools such > as network objects, etc., with support and testing needed in m3tk for > the new type, as well as in other tools like m3browser. This sounds great! As this topic had been discussed several times, and nothing ever came of it, I'd rather thought that it wouldn't be different this time. So at last we have explicit 64 bit support. I assume that this works on 32 bit platforms as well as an 64 bit platforms? 32 bit backends were the main problem when I tried to build code generation support some years ago, as suddenly everything needed to be 64 bit long in the CG interfaces. > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head just so that it gets some > testing, but perhaps that is premature. I can confirm a complete > bootstrap via "do-cm3-std.sh" that appears to produce perfectly > functional executables, including mentor, etc. Well, as there are no other major projects ongoing in development as far as I know there principally is no need for special care. If you can produce a working core system on two or three target platforms and provide upgrading instructions, we can put it in the main trunk. I'd strongly suggest to tag _everything_ before and after commit of the new code though, for example with cvs tag devel_LONGINT_start cvs commit cvs tag devel_LONGINT_RC01 just to make sure that we can easily revert to prior versions. We'll have to update the M3 language specs, too, and put up some HTML documentation on the servers. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Thu Jul 19 15:13:05 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 08:13:05 -0500 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F6361.9010407@wichita.edu> I'll volunteer to do the update to the language definition, as that is an interest of mine. Tony Hosking wrote: > I've successfully bootstrapped a CM3 compiler that supports LONGINT as > a 64-bit integer type (equivalent to "long long" in C) in addition to > INTEGER (same as "long" in C). This will be useful for simplifying > interfaces to C library routines that expect to be able to treat 64-bit > integers such as "off_t" for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type (I'm > not sure this would ever be a good idea) so it cannot be used to index > arrays, define enumerations etc., though the simple operations ABS, > MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, > assignment, are all supported. This includes changes to m3core (with > support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) > and libm3 for Pickle2, as well as to m3middle, m3front, and the > gcc-based compiler backend. There is still work that needs to be done > to support and test all the other M3 tools such as network objects, > etc., with support and testing needed in m3tk for the new type, as well > as in other tools like m3browser. > > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head just so that it gets some testing, > but perhaps that is premature. I can confirm a complete bootstrap via > "do-cm3-std.sh" that appears to produce perfectly functional > executables, including mentor, etc. > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 16:33:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 10:33:37 -0400 Subject: [M3devel] LONGINT In-Reply-To: <20070719062350.GA12517@elegosoft.com> References: <20070719062350.GA12517@elegosoft.com> Message-ID: On Jul 19, 2007, at 2:23 AM, Olaf Wagner wrote: > On Wed, Jul 18, 2007 at 11:53:38PM -0400, Tony Hosking wrote: >> I've successfully bootstrapped a CM3 compiler that supports LONGINT >> as a 64-bit integer type (equivalent to "long long" in C) in addition >> to INTEGER (same as "long" in C). This will be useful for >> simplifying interfaces to C library routines that expect to be able >> to treat 64-bit integers such as "off_t" for lseek, etc. >> >> Currently, the compiler does not treat LONGINT as an ordinal type >> (I'm not sure this would ever be a good idea) so it cannot be used to >> index arrays, define enumerations etc., though the simple operations >> ABS, MAX, MIN, addition, comparisons, MOD, multiplication, >> subtraction, assignment, are all supported. This includes changes to >> m3core (with support for Long.T similar to Word.T, plus RTTipe and >> RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, >> m3front, and the gcc-based compiler backend. There is still work >> that needs to be done to support and test all the other M3 tools such >> as network objects, etc., with support and testing needed in m3tk for >> the new type, as well as in other tools like m3browser. > > This sounds great! As this topic had been discussed several times, > and nothing ever came of it, I'd rather thought that it wouldn't > be different this time. So at last we have explicit 64 bit support. > I assume that this works on 32 bit platforms as well as an 64 bit > platforms? 32 bit backends were the main problem when I tried to > build code generation support some years ago, as suddenly everything > needed to be 64 bit long in the CG interfaces. What I did was to allow both INTEGER precision and LONGINT precision in M3CG/CG much along the lines of the various floating point precisions (REAL, LONGREAL, EXTENDED). It did require pushing support for these alternatives all the way through to the back-end though the changes are more cosmetic than major refactoring. CM3 is a pretty clean compiler in that respect. > >> How best should I proceed to get this out to the community. I am >> tempted to push it into the CVS head just so that it gets some >> testing, but perhaps that is premature. I can confirm a complete >> bootstrap via "do-cm3-std.sh" that appears to produce perfectly >> functional executables, including mentor, etc. > > Well, as there are no other major projects ongoing in development > as far as I know there principally is no need for special care. > If you can produce a working core system on two or three target > platforms and provide upgrading instructions, we can put it in the > main trunk. I'd strongly suggest to tag _everything_ before and > after commit of the new code though, for example with > > cvs tag devel_LONGINT_start > cvs commit > cvs tag devel_LONGINT_RC01 > > just to make sure that we can easily revert to prior versions. OK, I'll do this. > > We'll have to update the M3 language specs, too, and put up > some HTML documentation on the servers. Yes, indeed. I would be keen to get a clean integration of LONGINT in the specs that makes sense. My biggest question for now is whether we should consider LONGINT as an ordinal type or not. Perhaps there need to be two different classes of ordinal type with different base types (INTEGER and LONGINT). > > Thanks for all the work, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 > Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 > 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | > Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From hosking at cs.purdue.edu Thu Jul 19 16:34:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 10:34:22 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469F6361.9010407@wichita.edu> References: <469F6361.9010407@wichita.edu> Message-ID: <6D9BD083-9E4A-4C64-A1FB-5F840D28971E@cs.purdue.edu> On Jul 19, 2007, at 9:13 AM, Rodney M. Bates wrote: > I'll volunteer to do the update to the language definition, as that > is an > interest of mine. Great! Let's try to flesh this out soon so I can try to get the compiler up to speed with what we spec out. > > Tony Hosking wrote: >> I've successfully bootstrapped a CM3 compiler that supports >> LONGINT as a 64-bit integer type (equivalent to "long long" in C) >> in addition to INTEGER (same as "long" in C). This will be >> useful for simplifying interfaces to C library routines that >> expect to be able to treat 64-bit integers such as "off_t" for >> lseek, etc. >> Currently, the compiler does not treat LONGINT as an ordinal type >> (I'm not sure this would ever be a good idea) so it cannot be used >> to index arrays, define enumerations etc., though the simple >> operations ABS, MAX, MIN, addition, comparisons, MOD, >> multiplication, subtraction, assignment, are all supported. This >> includes changes to m3core (with support for Long.T similar to >> Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, >> as well as to m3middle, m3front, and the gcc-based compiler >> backend. There is still work that needs to be done to support >> and test all the other M3 tools such as network objects, etc., >> with support and testing needed in m3tk for the new type, as well >> as in other tools like m3browser. >> How best should I proceed to get this out to the community. I am >> tempted to push it into the CVS head just so that it gets some >> testing, but perhaps that is premature. I can confirm a complete >> bootstrap via "do-cm3-std.sh" that appears to produce perfectly >> functional executables, including mentor, etc. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 17:27:48 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 11:27:48 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> References: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> Message-ID: 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=, M3_CVvbAZ_session=0x1f93290, > M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', > M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid= 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=, > M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Thu Jul 19 17:31:23 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 11:31:23 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: My LONGINT implementation addresses many of your concerns. The LONGINT space is segregated from the INT space. I want to come up with an implementation that also permits ordinals based on LONGINT in addition to the current system of ordinals based on INTEGER. This requires revisiting the language spec and pushing through the implications. I'm going to look at that briefly before moving on to fixing user-level threading for all targets. On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: > Hello everyone, > > I have read the various proposals for supporting integers of different > bit sizes and am getting a little worried that they are running > away from the traditional Modula-3 simplicity. As far as I know, > there is very little in Modula-3 that depends on the actual size > in bits of INTEGERs and CARDINALs. It doesn't seem to me to make > much sense to introduce types like Int32.T and Int64.T and then > make the definition Int32.T = INTEGER (on one platform) and Int64.T > = INTEGER (on another platform). I'm wondering if it would instead > be possible to introduce a new group of types in the sense that > Modula-3 now has integer types and floating-point types, and call > these types "fixed width" or "specified width" types. Conversions > between these types and INTEGER or CARDINAL would have to be done > using functions (operators) that are the analogs of FLOAT, ROUND, > etc. Standard arithmetic operators would be overloaded just like > they are today for integers and floating-point numbers. Am I just > duplicating someone else's proposal here? Perhaps this proposal > doesn't address everything one might want to do with these extended- > size types? > > Maybe I am just dreaming about getting Modula-3 running on a > DECsystem-20 with 36-bit integers...with pickles that are > interchangeable > with i386 pickles, of course. > > What do people want to do with these extended-size types anyhow? > It seems good to me that INTEGER is the largest type that I can > expect my processor to calculate efficiently with. I would use > BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible > and write my code to be flexible about the BYTE/BITSIZE... but OK, > I can see the rationale for hiding all this in the compiler (and > inlining everything) in the few cases where I might want four-function > arithmetic on (specifically) 64- or 128-bit integers. > > Mika > > Darko writes: >> Actually I stated the wrong reason for that one, it's really an >> argument against mixed integer assignment. >> >> And saying that it looks right from the C/C++ point of view is pretty >> damning... >> >> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >> >>> Mail from unsubscribed address forwarded to the list... >>> ---------------------------- Original Message >>> ---------------------------- >>> Subject: Re: A nonnative 64-bit language proposal >>> From: hendrik at topoi.pooq.com >>> Date: Wed, October 25, 2006 14:22 >>> To: m3devel at elegosoft.com >>> -------------------------------------------------------------------- >>> -- >>> ---- >>> >>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>> >>>> For your example to compute as an integer even if that overflows >>>> and >>>> it wouldn't as a longint seems right from my C/C++ point of view. >>> >>> I've always thought C/C++ were badly wrong on this one, even >>> from their own archaic low-level machine-oriented viewpoint. >>> Most computers have integer multiply instructions that return a >>> double-length product. >>> >>> -- hendrik >>> >>> From rodney.bates at wichita.edu Thu Jul 19 19:34:13 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 12:34:13 -0500 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: <469FA095.2000404@wichita.edu> Tony Hosking wrote: > My LONGINT implementation addresses many of your concerns. The LONGINT > space is segregated from the INT space. I want to come up with an > implementation that also permits ordinals based on LONGINT in addition > to the current system of ordinals based on INTEGER. This requires > revisiting the language spec and pushing through the implications. I'm > going to look at that briefly before moving on to fixing user-level > threading for all targets. > By "ordinals", do you mean enumerations? Subranges?. In the language definition, ordinals refers to both the above, plus INTEGER, with CHAR and BOOLEAN being enumerations. It is hard to image a use for enumerations with more than 2^32 values. As I recall, I was thinking this would add quite a bit of complexity to the language for negligible benefit. Subranges of LONGINT seem entirely useful and make for consistency. From a language definition standpoint, I think these just about fall into place with very little change. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 19 20:56:16 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 19 Jul 2007 14:56:16 -0400 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F7BAD.1E75.00D7.1@scires.com> Tony: I'd like to better understand the implications of your change as I do use LONGINT as an index in some applications. 1. On a computer with a 32-bit word size, will LONGINT be 32 bits or 64 bits? 2. I assume on a computer with a 64-bit word size, LONGINT will be 64 bits. Is there an option to get a 32-bit integer on these machines? 3. Would it make sense to keep LONGINT at 32-bits and make a new type, say LONGINT64, at 64-bits? Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> Tony Hosking 7/18/2007 11:53 PM >>> I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 19 21:23:54 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:23:54 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FA095.2000404@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> Message-ID: Here are my notes from a run through the language spec. Next step is to flesh out the additional bits in the compiler beyond what I announced yesterday. I would appreciate any feedback you can give as I look into this. 3. TYPES -Ordinal Types: There are three kinds of ordinal types: enumerations, subranges, and integers. There are two integer types, which in order of increasing range and precision are INTEGER and LONGINT. The base type of an ordinal value 'v' is its type (INTEGER or LONGINT) if 'v' is an integer, otherwise it is the unique enumeration type that contains v. Subranges may have base type LONGINT. FIRST, LAST and NUMBER work for LONGINT. LONGINT is predeclared. Should the subrange [0..LAST(LONGINT)] be given a predeclared name? LONGCARD? -Array Types: Arrays may only be indexed by ordinals having an underlying INTEGER base type. [Otherwise, it will be difficult deciding the index type for open arrays.] -Set Types: It seems reasonable that SET OF Base, where the base type for Base is LONGINT, should be allowed. The restrictons on the number of elements in the base set remain (i.e., SET OF [0L..1023L] for elements having base type LONGINT will be practical, but not SET OF LONGINT). -Subtyping Rules: These remain the same for ordinals having LONGINT base type. 4. STATEMENTS. -Assignment: Since INTEGER and LONGINT have different base types they are not assignable. -For: FOR statements will function with LONGINT-based index types: FOR id := first TO last BY step DO S END where 'id' is an identifier, 'first' and 'last' are ordinal expressions with the same base type (e.g., LONGINT), step is an integer-valued expression of type INTEGER or LONGINT and S is a statement. If omitted 'step' defaults to 1 or 1L, depending on the base type of the loop bounds 'first' and 'last'. If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it should be rewritten as a WHILE loop to avoid overflow. -Case: CASE statements may take an expression whose type is an ordinal type with base type LONGINT. -Inc and Dec: INC and DEC function for both INTEGER-based and LONGINT-based ordinals. 7. EXPRESSIONS -Conventions for describing operations: The class 'Integer' will be used to describe the type class consisting of both INTEGER and LONGINT (similar to the use of 'Float'). -Numeric literals: Numeric literals denote constant non-negative integers or reals. The types of these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. A literal LONGINT has the same form as a literal INTEGER, except that it is suffixed with the character 'L'. Thus the LONGINT having value zero would be written '0L'. Moreover, if no explicit base is present, the value of the literal must be at most LAST(LONGINT). If an explicit base is present, the value of the literal must be less than '2^Long.Size', and its interpretation uses the convention of the 'Long' interface. -Arithmetic operations: We adjust the arithmetic operations as follows, where the type class 'Integer' can be one of INTEGER or LONGINT, FloatType represents the type of a type variable taking one of the values REAL, LONGREAL, or EXTENDED, and IntType represents the type of a type variable taking one of the values INTEGER or LONGINT. prefix + (x: Integer) : Integer (x: Float) : Float infix + (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set prefix - (x: Integer) : Integer (x: Float) : Float infix - (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set infix * (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set infix / (x,y: Float) : Float (x,y: Set) : Set infix DIV (x,y: Integer): Integer infix MOD (x,y: Integer): Integer (x,y: Float) : Float ABS (x: Integer) : Integer (x: Float) : Float FLOAT (x: Integer; T: FloatType := REAL): T (x: Float; T: FloatType := REAL): T FLOOR (x: Float; T: IntType := INTEGER) : T CEILING (x: Float; T: IntType := INTEGER) : T ROUND (r: Float; T: IntType := INTEGER) : T TRUNC (r: Float; T: IntType := INTEGER) : T MAX, MIN (x,y: Ordinal) : Ordinal (x,y: Float) : Float -Relations These functions as expected for LONGINT. -Type operations ORD (element: Ordinal): Integer VAL (i: Integer; T: OrdinalType): T These function as expected, except that ORD returns INTEGER for elements of enumeration types. Otherwise, ORD returns an integer of the same base type as the element. Similarly, for VAL, if T is an enumeration type, then i must be an INTEGER. Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then ORD(n) = VAL(n, T: IntType): = n It is a static error if 'n' is not of type 'T'. NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = LONGINT (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT (A: FixedArrayType): CARDINAL (a: Array) : CARDINAL FIRST (T: OrdinalType) : BaseType(T) (T: FloatType) : T (A: FixedArrayType): BaseType(IndexType(A)) (a: Array) : BaseType(IndexType(a)) LAST (T: OrdinalType) : BaseType(T) (T: FloatType) : T (A: FixedArrayType): BaseType(IndexType(A)) (a: Array) : BaseType(IndexType(a)) BITSIZE (x: Any) : CARDINAL (T: Type): CARDINAL BYTESIZE (x: Any) : CARDINAL (T: Type): CARDINAL ADRSIZE (x: Any) : CARDINAL (T: Type): CARDINAL 9. REQUIRED INTERFACES There is an additional required interface 'Long', analogous to 'Word' except that Long.T = LONGINT On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> My LONGINT implementation addresses many of your concerns. The >> LONGINT space is segregated from the INT space. I want to come >> up with an implementation that also permits ordinals based on >> LONGINT in addition to the current system of ordinals based on >> INTEGER. This requires revisiting the language spec and pushing >> through the implications. I'm going to look at that briefly >> before moving on to fixing user-level threading for all targets. > > By "ordinals", do you mean enumerations? Subranges?. In the language > definition, ordinals refers to both the above, plus INTEGER, with > CHAR and > BOOLEAN being enumerations. > > It is hard to image a use for enumerations with more than 2^32 values. > As I recall, I was thinking this would add quite a bit of > complexity to > the language for negligible benefit. > > Subranges of LONGINT seem entirely useful and make for consistency. > From a language definition standpoint, I think these just about fall > into place with very little change. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 21:31:54 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:31:54 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> Message-ID: Yes, I will make bootstrapped compilers available in the usual place. Note that as soon as I check in the updates to CVS then old bootstrap compilers will no longer be able to compile m3core, since it mentions the type LONGINT in the Long.i3 interface. Building with a compiler that supports LONGINT will involve the following bootstrap process: 1. Build and ship the old versions of m3core and libm3. 2. Build and ship m3middle, m3linker, m3front, m3quake, cm3 3. Build and ship the new version of the sources via do-cm3-std.sh using the compiler from step 2 (in INSTALL_ROOT/pkg/cm3/TARGET/cm3). Easiest way to do this is to "export CM3=INSTALL_ROOT/pkg/cm3/ TARGET/cm3" (where INSTALL_ROOT and TARGET match your system) and then execute: do-cm3-std.sh realclean do-cm3-std.sh buildship from the scripts sub-directory of a clean CVS checkout I'll send a message once I have compilers available on my ftp site. On Jul 19, 2007, at 2:41 PM, Darko wrote: > This really is great stuff Tony, thanks for doing the hard yards. > Will you be making a build of this available in your usual spot? > > I'd like to try this out for a while and look for creative ways to > make it break (no offence intended) and get a feel for where it > needs to be extended. In the spirit of the M3 founding fathers, I > think we need some experience with this and then look at the > simplest and smallest change we can do to support what is missing. > > Cheers, > Darko. > > > On 19/07/2007, at 5:31 PM, Tony Hosking wrote: > >> My LONGINT implementation addresses many of your concerns. The >> LONGINT space is segregated from the INT space. I want to come up >> with an implementation that also permits ordinals based on LONGINT >> in addition to the current system of ordinals based on INTEGER. >> This requires revisiting the language spec and pushing through the >> implications. I'm going to look at that briefly before moving on >> to fixing user-level threading for all targets. >> >> On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: >> >>> Hello everyone, >>> >>> I have read the various proposals for supporting integers of >>> different >>> bit sizes and am getting a little worried that they are running >>> away from the traditional Modula-3 simplicity. As far as I know, >>> there is very little in Modula-3 that depends on the actual size >>> in bits of INTEGERs and CARDINALs. It doesn't seem to me to make >>> much sense to introduce types like Int32.T and Int64.T and then >>> make the definition Int32.T = INTEGER (on one platform) and Int64.T >>> = INTEGER (on another platform). I'm wondering if it would instead >>> be possible to introduce a new group of types in the sense that >>> Modula-3 now has integer types and floating-point types, and call >>> these types "fixed width" or "specified width" types. Conversions >>> between these types and INTEGER or CARDINAL would have to be done >>> using functions (operators) that are the analogs of FLOAT, ROUND, >>> etc. Standard arithmetic operators would be overloaded just like >>> they are today for integers and floating-point numbers. Am I just >>> duplicating someone else's proposal here? Perhaps this proposal >>> doesn't address everything one might want to do with these extended- >>> size types? >>> >>> Maybe I am just dreaming about getting Modula-3 running on a >>> DECsystem-20 with 36-bit integers...with pickles that are >>> interchangeable >>> with i386 pickles, of course. >>> >>> What do people want to do with these extended-size types anyhow? >>> It seems good to me that INTEGER is the largest type that I can >>> expect my processor to calculate efficiently with. I would use >>> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible >>> and write my code to be flexible about the BYTE/BITSIZE... but OK, >>> I can see the rationale for hiding all this in the compiler (and >>> inlining everything) in the few cases where I might want four- >>> function >>> arithmetic on (specifically) 64- or 128-bit integers. >>> >>> Mika >>> >>> Darko writes: >>>> Actually I stated the wrong reason for that one, it's really an >>>> argument against mixed integer assignment. >>>> >>>> And saying that it looks right from the C/C++ point of view is >>>> pretty >>>> damning... >>>> >>>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >>>> >>>>> Mail from unsubscribed address forwarded to the list... >>>>> ---------------------------- Original Message >>>>> ---------------------------- >>>>> Subject: Re: A nonnative 64-bit language proposal >>>>> From: hendrik at topoi.pooq.com >>>>> Date: Wed, October 25, 2006 14:22 >>>>> To: m3devel at elegosoft.com >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>> ---- >>>>> >>>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>>>> >>>>>> For your example to compute as an integer even if that >>>>>> overflows and >>>>>> it wouldn't as a longint seems right from my C/C++ point of view. >>>>> >>>>> I've always thought C/C++ were badly wrong on this one, even >>>>> from their own archaic low-level machine-oriented viewpoint. >>>>> Most computers have integer multiply instructions that return a >>>>> double-length product. >>>>> >>>>> -- hendrik >>>>> >>>>> >> From hosking at cs.purdue.edu Thu Jul 19 21:44:18 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:44:18 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469F7BAD.1E75.00D7.1@scires.com> References: <469F7BAD.1E75.00D7.1@scires.com> Message-ID: <7C096B2E-9366-4CC0-A03D-B06BFAF40FF8@cs.purdue.edu> On Jul 19, 2007, at 2:56 PM, Randy Coleburn wrote: > Tony: > > I'd like to better understand the implications of your change as I > do use LONGINT as an index in some applications. In that case, what is the index type of an open array: ARRAY OF X? I assume that dope vectors for open arrays will need to indicate the index type. Moreover, code compiled to manipulate ARRAY OF X will need to cope with dynamically-determined index types. My inclination is to avoid this pain by prohibiting ordinals with base type LONGINT from being used as the index type for arrays. > > 1. On a computer with a 32-bit word size, will LONGINT be 32 bits > or 64 bits? LONGINT will be the same as C "long long" which is 64 bits on a 32- bit machine. INTEGER will continue to be the same as C "long" which is 32 bits on a 32-bit machine. On a 64-bit machine, both INTEGER and LONGINT will be 64 bits. > 2. I assume on a computer with a 64-bit word size, LONGINT will be > 64 bits. Is there an option to get a 32-bit integer on these > machines? What's wrong with "BITS 32 FOR [-16_80000000 .. 16_7fffffff]"? > 3. Would it make sense to keep LONGINT at 32-bits and make a new > type, say LONGINT64, at 64-bits? I don't think anyone should make any assumption in portable code about LONGINT and INTEGER other than that BITSIZE(INTEGER) <= BITSIZE(LONGINT) When assuming a given target I think it is reasonable to assume: BITSIZE(INTEGER) = sizeof (long) BITSIZE(LONGINT) = sizeof (long long) so that we have a convenient mapping to C header files and interfaces. > > Regards, > Randy > > Randy C. Coleburn > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." > > >>> Tony Hosking 7/18/2007 11:53 PM >>> > I've successfully bootstrapped a CM3 compiler that supports LONGINT > as a 64-bit integer type (equivalent to "long long" in C) in addition > to INTEGER (same as "long" in C). This will be useful for > simplifying interfaces to C library routines that expect to be able > to treat 64-bit integers such as "off_t" ! for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type > (I'm not sure this would ever be a good idea) so it cannot be used to > index arrays, define enumerations etc., though the simple operations > ABS, MAX, MIN, addition, comparisons, MOD, multiplication, > subtraction, assignment, are all supported. This includes changes to > m3core (with support for Long.T similar to Word.T, plus RTTipe and > RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, > m3front, and the gcc-based compiler backend. There is still work > that needs to be done to support and test all the other M3 tools such > as network objects, etc., with support and testing needed in m3tk for > the new type, as well as in other tools like m3browser. > > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head jus! t so that it gets some > testing, but perhaps that is prematur e. I can confirm a complete > bootstrap via "do-cm3-std.sh" that appears to produce perfectly > functional executables, including mentor, etc. > > From darko at darko.org Thu Jul 19 22:23:27 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 22:23:27 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> Message-ID: <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> Have I missed something or is there no way to assign between INTEGER and LONGINT? Is there an explicit conversion function that I've overlooked? Would assignment be so bad here since there would be an implicit range check, much like when you assign between two overlapping subranges? In a sense these two types are integer subranges of an abstract integer type containing all integers. n 19/07/2007, at 9:23 PM, Tony Hosking wrote: > Here are my notes from a run through the language spec. Next step > is to flesh out the additional bits in the compiler beyond what I > announced yesterday. I would appreciate any feedback you can give > as I look into this. > > 3. TYPES > > -Ordinal Types: > > There are three kinds of ordinal types: enumerations, subranges, and > integers. There are two integer types, which in order of > increasing range and > precision are INTEGER and LONGINT. > > The base type of an ordinal value 'v' is its type (INTEGER or > LONGINT) if 'v' > is an integer, otherwise it is the unique enumeration type that > contains v. > > Subranges may have base type LONGINT. > > FIRST, LAST and NUMBER work for LONGINT. > > LONGINT is predeclared. > > Should the subrange [0..LAST(LONGINT)] be given a predeclared > name? LONGCARD? > > -Array Types: > > Arrays may only be indexed by ordinals having an underlying INTEGER > base type. > [Otherwise, it will be difficult deciding the index type for open > arrays.] > > -Set Types: > > It seems reasonable that SET OF Base, where the base type for Base > is LONGINT, > should be allowed. The restrictons on the number of elements in > the base set > remain (i.e., SET OF [0L..1023L] for elements having base type > LONGINT will be > practical, but not SET OF LONGINT). > > -Subtyping Rules: > > These remain the same for ordinals having LONGINT base type. > > > 4. STATEMENTS. > > -Assignment: > > Since INTEGER and LONGINT have different base types they are not > assignable. > > -For: > > FOR statements will function with LONGINT-based index types: > > FOR id := first TO last BY step DO S END > > where 'id' is an identifier, 'first' and 'last' are ordinal > expressions with > the same base type (e.g., LONGINT), step is an integer-valued > expression of > type INTEGER or LONGINT and S is a statement. If omitted 'step' > defaults to 1 > or 1L, depending on the base type of the loop bounds 'first' and > 'last'. > > If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it > should be rewritten as a WHILE loop to avoid overflow. > > -Case: > > CASE statements may take an expression whose type is an ordinal > type with base > type LONGINT. > > -Inc and Dec: > > INC and DEC function for both INTEGER-based and LONGINT-based > ordinals. > > 7. EXPRESSIONS > > -Conventions for describing operations: > > The class 'Integer' will be used to describe the type class > consisting of both > INTEGER and LONGINT (similar to the use of 'Float'). > > -Numeric literals: > > Numeric literals denote constant non-negative integers or reals. > The types of > these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. > > A literal LONGINT has the same form as a literal INTEGER, except > that it is > suffixed with the character 'L'. Thus the LONGINT having value > zero would be > written '0L'. Moreover, if no explicit base is present, the value > of the > literal must be at most LAST(LONGINT). If an explicit base is > present, the > value of the literal must be less than '2^Long.Size', and its > interpretation > uses the convention of the 'Long' interface. > > -Arithmetic operations: > > We adjust the arithmetic operations as follows, where the type > class 'Integer' > can be one of INTEGER or LONGINT, FloatType represents the type of > a type > variable taking one of the values REAL, LONGREAL, or EXTENDED, and > IntType > represents the type of a type variable taking one of the values > INTEGER or LONGINT. > > prefix + (x: Integer) : Integer > (x: Float) : Float > > infix + (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > prefix - (x: Integer) : Integer > (x: Float) : Float > > infix - (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > infix * (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > infix / (x,y: Float) : Float > (x,y: Set) : Set > > infix DIV (x,y: Integer): Integer > > infix MOD (x,y: Integer): Integer > (x,y: Float) : Float > > ABS (x: Integer) : Integer > (x: Float) : Float > > FLOAT (x: Integer; T: FloatType := REAL): T > (x: Float; T: FloatType := REAL): T > > FLOOR (x: Float; T: IntType := INTEGER) : T > CEILING (x: Float; T: IntType := INTEGER) : T > > ROUND (r: Float; T: IntType := INTEGER) : T > TRUNC (r: Float; T: IntType := INTEGER) : T > > MAX, MIN (x,y: Ordinal) : Ordinal > (x,y: Float) : Float > > -Relations > > These functions as expected for LONGINT. > > -Type operations > > ORD (element: Ordinal): Integer > VAL (i: Integer; T: OrdinalType): T > > These function as expected, except that ORD returns INTEGER for > elements of > enumeration types. Otherwise, ORD returns an integer of the same > base type as > the element. Similarly, for VAL, if T is an enumeration type, then > i must be > an INTEGER. > > Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then > > ORD(n) = VAL(n, T: IntType): = n > > It is a static error if 'n' is not of type 'T'. > > NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = > LONGINT > (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT > (A: FixedArrayType): CARDINAL > (a: Array) : CARDINAL > > FIRST (T: OrdinalType) : BaseType(T) > (T: FloatType) : T > (A: FixedArrayType): BaseType(IndexType(A)) > (a: Array) : BaseType(IndexType(a)) > LAST (T: OrdinalType) : BaseType(T) > (T: FloatType) : T > (A: FixedArrayType): BaseType(IndexType(A)) > (a: Array) : BaseType(IndexType(a)) > > BITSIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > BYTESIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > ADRSIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > > 9. REQUIRED INTERFACES > > There is an additional required interface 'Long', analogous to > 'Word' except that > > Long.T = LONGINT > > > On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: > >> >> >> Tony Hosking wrote: >>> My LONGINT implementation addresses many of your concerns. The >>> LONGINT space is segregated from the INT space. I want to come >>> up with an implementation that also permits ordinals based on >>> LONGINT in addition to the current system of ordinals based on >>> INTEGER. This requires revisiting the language spec and pushing >>> through the implications. I'm going to look at that briefly >>> before moving on to fixing user-level threading for all targets. >> >> By "ordinals", do you mean enumerations? Subranges?. In the >> language >> definition, ordinals refers to both the above, plus INTEGER, with >> CHAR and >> BOOLEAN being enumerations. >> >> It is hard to image a use for enumerations with more than 2^32 >> values. >> As I recall, I was thinking this would add quite a bit of >> complexity to >> the language for negligible benefit. >> >> Subranges of LONGINT seem entirely useful and make for consistency. >> From a language definition standpoint, I think these just about fall >> into place with very little change. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > From hosking at cs.purdue.edu Thu Jul 19 22:26:38 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 16:26:38 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> Message-ID: <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> This is a good question. I would assume that conversion must be explicit to fit with the M3 philosophy. It would make sense to have a conversion operation that performs the appropriate range check? Any ideas for a name for the operation. On Jul 19, 2007, at 4:23 PM, Darko wrote: > Have I missed something or is there no way to assign between > INTEGER and LONGINT? Is there an explicit conversion function that > I've overlooked? Would assignment be so bad here since there would > be an implicit range check, much like when you assign between two > overlapping subranges? In a sense these two types are integer > subranges of an abstract integer type containing all integers. > > > n 19/07/2007, at 9:23 PM, Tony Hosking wrote: > >> Here are my notes from a run through the language spec. Next step >> is to flesh out the additional bits in the compiler beyond what I >> announced yesterday. I would appreciate any feedback you can give >> as I look into this. >> >> 3. TYPES >> >> -Ordinal Types: >> >> There are three kinds of ordinal types: enumerations, subranges, and >> integers. There are two integer types, which in order of >> increasing range and >> precision are INTEGER and LONGINT. >> >> The base type of an ordinal value 'v' is its type (INTEGER or >> LONGINT) if 'v' >> is an integer, otherwise it is the unique enumeration type that >> contains v. >> >> Subranges may have base type LONGINT. >> >> FIRST, LAST and NUMBER work for LONGINT. >> >> LONGINT is predeclared. >> >> Should the subrange [0..LAST(LONGINT)] be given a predeclared >> name? LONGCARD? >> >> -Array Types: >> >> Arrays may only be indexed by ordinals having an underlying >> INTEGER base type. >> [Otherwise, it will be difficult deciding the index type for open >> arrays.] >> >> -Set Types: >> >> It seems reasonable that SET OF Base, where the base type for Base >> is LONGINT, >> should be allowed. The restrictons on the number of elements in >> the base set >> remain (i.e., SET OF [0L..1023L] for elements having base type >> LONGINT will be >> practical, but not SET OF LONGINT). >> >> -Subtyping Rules: >> >> These remain the same for ordinals having LONGINT base type. >> >> >> 4. STATEMENTS. >> >> -Assignment: >> >> Since INTEGER and LONGINT have different base types they are not >> assignable. >> >> -For: >> >> FOR statements will function with LONGINT-based index types: >> >> FOR id := first TO last BY step DO S END >> >> where 'id' is an identifier, 'first' and 'last' are ordinal >> expressions with >> the same base type (e.g., LONGINT), step is an integer-valued >> expression of >> type INTEGER or LONGINT and S is a statement. If omitted 'step' >> defaults to 1 >> or 1L, depending on the base type of the loop bounds 'first' and >> 'last'. >> >> If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it >> should be rewritten as a WHILE loop to avoid overflow. >> >> -Case: >> >> CASE statements may take an expression whose type is an ordinal >> type with base >> type LONGINT. >> >> -Inc and Dec: >> >> INC and DEC function for both INTEGER-based and LONGINT-based >> ordinals. >> >> 7. EXPRESSIONS >> >> -Conventions for describing operations: >> >> The class 'Integer' will be used to describe the type class >> consisting of both >> INTEGER and LONGINT (similar to the use of 'Float'). >> >> -Numeric literals: >> >> Numeric literals denote constant non-negative integers or reals. >> The types of >> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >> >> A literal LONGINT has the same form as a literal INTEGER, except >> that it is >> suffixed with the character 'L'. Thus the LONGINT having value >> zero would be >> written '0L'. Moreover, if no explicit base is present, the value >> of the >> literal must be at most LAST(LONGINT). If an explicit base is >> present, the >> value of the literal must be less than '2^Long.Size', and its >> interpretation >> uses the convention of the 'Long' interface. >> >> -Arithmetic operations: >> >> We adjust the arithmetic operations as follows, where the type >> class 'Integer' >> can be one of INTEGER or LONGINT, FloatType represents the type of >> a type >> variable taking one of the values REAL, LONGREAL, or EXTENDED, and >> IntType >> represents the type of a type variable taking one of the values >> INTEGER or LONGINT. >> >> prefix + (x: Integer) : Integer >> (x: Float) : Float >> >> infix + (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> prefix - (x: Integer) : Integer >> (x: Float) : Float >> >> infix - (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix * (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix / (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix DIV (x,y: Integer): Integer >> >> infix MOD (x,y: Integer): Integer >> (x,y: Float) : Float >> >> ABS (x: Integer) : Integer >> (x: Float) : Float >> >> FLOAT (x: Integer; T: FloatType := REAL): T >> (x: Float; T: FloatType := REAL): T >> >> FLOOR (x: Float; T: IntType := INTEGER) : T >> CEILING (x: Float; T: IntType := INTEGER) : T >> >> ROUND (r: Float; T: IntType := INTEGER) : T >> TRUNC (r: Float; T: IntType := INTEGER) : T >> >> MAX, MIN (x,y: Ordinal) : Ordinal >> (x,y: Float) : Float >> >> -Relations >> >> These functions as expected for LONGINT. >> >> -Type operations >> >> ORD (element: Ordinal): Integer >> VAL (i: Integer; T: OrdinalType): T >> >> These function as expected, except that ORD returns INTEGER for >> elements of >> enumeration types. Otherwise, ORD returns an integer of the same >> base type as >> the element. Similarly, for VAL, if T is an enumeration type, >> then i must be >> an INTEGER. >> >> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >> >> ORD(n) = VAL(n, T: IntType): = n >> >> It is a static error if 'n' is not of type 'T'. >> >> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = >> LONGINT >> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >> (A: FixedArrayType): CARDINAL >> (a: Array) : CARDINAL >> >> FIRST (T: OrdinalType) : BaseType(T) >> (T: FloatType) : T >> (A: FixedArrayType): BaseType(IndexType(A)) >> (a: Array) : BaseType(IndexType(a)) >> LAST (T: OrdinalType) : BaseType(T) >> (T: FloatType) : T >> (A: FixedArrayType): BaseType(IndexType(A)) >> (a: Array) : BaseType(IndexType(a)) >> >> BITSIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> BYTESIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> ADRSIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> >> 9. REQUIRED INTERFACES >> >> There is an additional required interface 'Long', analogous to >> 'Word' except that >> >> Long.T = LONGINT >> >> >> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >> >>> >>> >>> Tony Hosking wrote: >>>> My LONGINT implementation addresses many of your concerns. The >>>> LONGINT space is segregated from the INT space. I want to come >>>> up with an implementation that also permits ordinals based on >>>> LONGINT in addition to the current system of ordinals based on >>>> INTEGER. This requires revisiting the language spec and >>>> pushing through the implications. I'm going to look at that >>>> briefly before moving on to fixing user-level threading for all >>>> targets. >>> >>> By "ordinals", do you mean enumerations? Subranges?. In the >>> language >>> definition, ordinals refers to both the above, plus INTEGER, with >>> CHAR and >>> BOOLEAN being enumerations. >>> >>> It is hard to image a use for enumerations with more than 2^32 >>> values. >>> As I recall, I was thinking this would add quite a bit of >>> complexity to >>> the language for negligible benefit. >>> >>> Subranges of LONGINT seem entirely useful and make for consistency. >>> From a language definition standpoint, I think these just about fall >>> into place with very little change. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu >> From darko at darko.org Thu Jul 19 22:33:04 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 22:33:04 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> Message-ID: <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> I actually favour a implicit conversion, which for this particular case I think would be consistent with existing M3 behaviour. On 19/07/2007, at 10:26 PM, Tony Hosking wrote: > This is a good question. I would assume that conversion must be > explicit to fit with the M3 philosophy. It would make sense to > have a conversion operation that performs the appropriate range > check? Any ideas for a name for the operation. > > On Jul 19, 2007, at 4:23 PM, Darko wrote: > >> Have I missed something or is there no way to assign between >> INTEGER and LONGINT? Is there an explicit conversion function that >> I've overlooked? Would assignment be so bad here since there would >> be an implicit range check, much like when you assign between two >> overlapping subranges? In a sense these two types are integer >> subranges of an abstract integer type containing all integers. >> >> >> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >> >>> Here are my notes from a run through the language spec. Next >>> step is to flesh out the additional bits in the compiler beyond >>> what I announced yesterday. I would appreciate any feedback you >>> can give as I look into this. >>> >>> 3. TYPES >>> >>> -Ordinal Types: >>> >>> There are three kinds of ordinal types: enumerations, subranges, and >>> integers. There are two integer types, which in order of >>> increasing range and >>> precision are INTEGER and LONGINT. >>> >>> The base type of an ordinal value 'v' is its type (INTEGER or >>> LONGINT) if 'v' >>> is an integer, otherwise it is the unique enumeration type that >>> contains v. >>> >>> Subranges may have base type LONGINT. >>> >>> FIRST, LAST and NUMBER work for LONGINT. >>> >>> LONGINT is predeclared. >>> >>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>> name? LONGCARD? >>> >>> -Array Types: >>> >>> Arrays may only be indexed by ordinals having an underlying >>> INTEGER base type. >>> [Otherwise, it will be difficult deciding the index type for open >>> arrays.] >>> >>> -Set Types: >>> >>> It seems reasonable that SET OF Base, where the base type for >>> Base is LONGINT, >>> should be allowed. The restrictons on the number of elements in >>> the base set >>> remain (i.e., SET OF [0L..1023L] for elements having base type >>> LONGINT will be >>> practical, but not SET OF LONGINT). >>> >>> -Subtyping Rules: >>> >>> These remain the same for ordinals having LONGINT base type. >>> >>> >>> 4. STATEMENTS. >>> >>> -Assignment: >>> >>> Since INTEGER and LONGINT have different base types they are not >>> assignable. >>> >>> -For: >>> >>> FOR statements will function with LONGINT-based index types: >>> >>> FOR id := first TO last BY step DO S END >>> >>> where 'id' is an identifier, 'first' and 'last' are ordinal >>> expressions with >>> the same base type (e.g., LONGINT), step is an integer-valued >>> expression of >>> type INTEGER or LONGINT and S is a statement. If omitted 'step' >>> defaults to 1 >>> or 1L, depending on the base type of the loop bounds 'first' and >>> 'last'. >>> >>> If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it >>> should be rewritten as a WHILE loop to avoid overflow. >>> >>> -Case: >>> >>> CASE statements may take an expression whose type is an ordinal >>> type with base >>> type LONGINT. >>> >>> -Inc and Dec: >>> >>> INC and DEC function for both INTEGER-based and LONGINT-based >>> ordinals. >>> >>> 7. EXPRESSIONS >>> >>> -Conventions for describing operations: >>> >>> The class 'Integer' will be used to describe the type class >>> consisting of both >>> INTEGER and LONGINT (similar to the use of 'Float'). >>> >>> -Numeric literals: >>> >>> Numeric literals denote constant non-negative integers or reals. >>> The types of >>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>> >>> A literal LONGINT has the same form as a literal INTEGER, except >>> that it is >>> suffixed with the character 'L'. Thus the LONGINT having value >>> zero would be >>> written '0L'. Moreover, if no explicit base is present, the >>> value of the >>> literal must be at most LAST(LONGINT). If an explicit base is >>> present, the >>> value of the literal must be less than '2^Long.Size', and its >>> interpretation >>> uses the convention of the 'Long' interface. >>> >>> -Arithmetic operations: >>> >>> We adjust the arithmetic operations as follows, where the type >>> class 'Integer' >>> can be one of INTEGER or LONGINT, FloatType represents the type >>> of a type >>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>> and IntType >>> represents the type of a type variable taking one of the values >>> INTEGER or LONGINT. >>> >>> prefix + (x: Integer) : Integer >>> (x: Float) : Float >>> >>> infix + (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> prefix - (x: Integer) : Integer >>> (x: Float) : Float >>> >>> infix - (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix * (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix / (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix DIV (x,y: Integer): Integer >>> >>> infix MOD (x,y: Integer): Integer >>> (x,y: Float) : Float >>> >>> ABS (x: Integer) : Integer >>> (x: Float) : Float >>> >>> FLOAT (x: Integer; T: FloatType := REAL): T >>> (x: Float; T: FloatType := REAL): T >>> >>> FLOOR (x: Float; T: IntType := INTEGER) : T >>> CEILING (x: Float; T: IntType := INTEGER) : T >>> >>> ROUND (r: Float; T: IntType := INTEGER) : T >>> TRUNC (r: Float; T: IntType := INTEGER) : T >>> >>> MAX, MIN (x,y: Ordinal) : Ordinal >>> (x,y: Float) : Float >>> >>> -Relations >>> >>> These functions as expected for LONGINT. >>> >>> -Type operations >>> >>> ORD (element: Ordinal): Integer >>> VAL (i: Integer; T: OrdinalType): T >>> >>> These function as expected, except that ORD returns INTEGER for >>> elements of >>> enumeration types. Otherwise, ORD returns an integer of the same >>> base type as >>> the element. Similarly, for VAL, if T is an enumeration type, >>> then i must be >>> an INTEGER. >>> >>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>> >>> ORD(n) = VAL(n, T: IntType): = n >>> >>> It is a static error if 'n' is not of type 'T'. >>> >>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) >>> = LONGINT >>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >>> (A: FixedArrayType): CARDINAL >>> (a: Array) : CARDINAL >>> >>> FIRST (T: OrdinalType) : BaseType(T) >>> (T: FloatType) : T >>> (A: FixedArrayType): BaseType(IndexType(A)) >>> (a: Array) : BaseType(IndexType(a)) >>> LAST (T: OrdinalType) : BaseType(T) >>> (T: FloatType) : T >>> (A: FixedArrayType): BaseType(IndexType(A)) >>> (a: Array) : BaseType(IndexType(a)) >>> >>> BITSIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> BYTESIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> ADRSIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> >>> 9. REQUIRED INTERFACES >>> >>> There is an additional required interface 'Long', analogous to >>> 'Word' except that >>> >>> Long.T = LONGINT >>> >>> >>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>> >>>> >>>> >>>> Tony Hosking wrote: >>>>> My LONGINT implementation addresses many of your concerns. >>>>> The LONGINT space is segregated from the INT space. I want to >>>>> come up with an implementation that also permits ordinals >>>>> based on LONGINT in addition to the current system of ordinals >>>>> based on INTEGER. This requires revisiting the language spec >>>>> and pushing through the implications. I'm going to look at >>>>> that briefly before moving on to fixing user-level threading >>>>> for all targets. >>>> >>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>> language >>>> definition, ordinals refers to both the above, plus INTEGER, >>>> with CHAR and >>>> BOOLEAN being enumerations. >>>> >>>> It is hard to image a use for enumerations with more than 2^32 >>>> values. >>>> As I recall, I was thinking this would add quite a bit of >>>> complexity to >>>> the language for negligible benefit. >>>> >>>> Subranges of LONGINT seem entirely useful and make for consistency. >>>> From a language definition standpoint, I think these just about >>>> fall >>>> into place with very little change. >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu >>> > From hosking at cs.purdue.edu Thu Jul 19 22:50:50 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 16:50:50 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: On Jul 19, 2007, at 4:33 PM, Darko wrote: > I actually favour a implicit conversion, which for this particular > case I think would be consistent with existing M3 behaviour. There is no implicit conversion for floats. The danger with implicit conversion for integers is that it would not be portable: you would get different behavior on different machines for the same code. Better to make the conversion explicit so that programmers are prepared for the range check to fail. > > > On 19/07/2007, at 10:26 PM, Tony Hosking wrote: > >> This is a good question. I would assume that conversion must be >> explicit to fit with the M3 philosophy. It would make sense to >> have a conversion operation that performs the appropriate range >> check? Any ideas for a name for the operation. >> >> On Jul 19, 2007, at 4:23 PM, Darko wrote: >> >>> Have I missed something or is there no way to assign between >>> INTEGER and LONGINT? Is there an explicit conversion function >>> that I've overlooked? Would assignment be so bad here since there >>> would be an implicit range check, much like when you assign >>> between two overlapping subranges? In a sense these two types are >>> integer subranges of an abstract integer type containing all >>> integers. >>> >>> >>> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >>> >>>> Here are my notes from a run through the language spec. Next >>>> step is to flesh out the additional bits in the compiler beyond >>>> what I announced yesterday. I would appreciate any feedback you >>>> can give as I look into this. >>>> >>>> 3. TYPES >>>> >>>> -Ordinal Types: >>>> >>>> There are three kinds of ordinal types: enumerations, subranges, >>>> and >>>> integers. There are two integer types, which in order of >>>> increasing range and >>>> precision are INTEGER and LONGINT. >>>> >>>> The base type of an ordinal value 'v' is its type (INTEGER or >>>> LONGINT) if 'v' >>>> is an integer, otherwise it is the unique enumeration type that >>>> contains v. >>>> >>>> Subranges may have base type LONGINT. >>>> >>>> FIRST, LAST and NUMBER work for LONGINT. >>>> >>>> LONGINT is predeclared. >>>> >>>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>>> name? LONGCARD? >>>> >>>> -Array Types: >>>> >>>> Arrays may only be indexed by ordinals having an underlying >>>> INTEGER base type. >>>> [Otherwise, it will be difficult deciding the index type for >>>> open arrays.] >>>> >>>> -Set Types: >>>> >>>> It seems reasonable that SET OF Base, where the base type for >>>> Base is LONGINT, >>>> should be allowed. The restrictons on the number of elements in >>>> the base set >>>> remain (i.e., SET OF [0L..1023L] for elements having base type >>>> LONGINT will be >>>> practical, but not SET OF LONGINT). >>>> >>>> -Subtyping Rules: >>>> >>>> These remain the same for ordinals having LONGINT base type. >>>> >>>> >>>> 4. STATEMENTS. >>>> >>>> -Assignment: >>>> >>>> Since INTEGER and LONGINT have different base types they are not >>>> assignable. >>>> >>>> -For: >>>> >>>> FOR statements will function with LONGINT-based index types: >>>> >>>> FOR id := first TO last BY step DO S END >>>> >>>> where 'id' is an identifier, 'first' and 'last' are ordinal >>>> expressions with >>>> the same base type (e.g., LONGINT), step is an integer-valued >>>> expression of >>>> type INTEGER or LONGINT and S is a statement. If omitted 'step' >>>> defaults to 1 >>>> or 1L, depending on the base type of the loop bounds 'first' and >>>> 'last'. >>>> >>>> If the upper bound of the loop is LAST(INTEGER) or LAST >>>> (LONGINT), it >>>> should be rewritten as a WHILE loop to avoid overflow. >>>> >>>> -Case: >>>> >>>> CASE statements may take an expression whose type is an ordinal >>>> type with base >>>> type LONGINT. >>>> >>>> -Inc and Dec: >>>> >>>> INC and DEC function for both INTEGER-based and LONGINT-based >>>> ordinals. >>>> >>>> 7. EXPRESSIONS >>>> >>>> -Conventions for describing operations: >>>> >>>> The class 'Integer' will be used to describe the type class >>>> consisting of both >>>> INTEGER and LONGINT (similar to the use of 'Float'). >>>> >>>> -Numeric literals: >>>> >>>> Numeric literals denote constant non-negative integers or reals. >>>> The types of >>>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>>> >>>> A literal LONGINT has the same form as a literal INTEGER, except >>>> that it is >>>> suffixed with the character 'L'. Thus the LONGINT having value >>>> zero would be >>>> written '0L'. Moreover, if no explicit base is present, the >>>> value of the >>>> literal must be at most LAST(LONGINT). If an explicit base is >>>> present, the >>>> value of the literal must be less than '2^Long.Size', and its >>>> interpretation >>>> uses the convention of the 'Long' interface. >>>> >>>> -Arithmetic operations: >>>> >>>> We adjust the arithmetic operations as follows, where the type >>>> class 'Integer' >>>> can be one of INTEGER or LONGINT, FloatType represents the type >>>> of a type >>>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>>> and IntType >>>> represents the type of a type variable taking one of the values >>>> INTEGER or LONGINT. >>>> >>>> prefix + (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> infix + (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> prefix - (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> infix - (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix * (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix / (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix DIV (x,y: Integer): Integer >>>> >>>> infix MOD (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> >>>> ABS (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> FLOAT (x: Integer; T: FloatType := REAL): T >>>> (x: Float; T: FloatType := REAL): T >>>> >>>> FLOOR (x: Float; T: IntType := INTEGER) : T >>>> CEILING (x: Float; T: IntType := INTEGER) : T >>>> >>>> ROUND (r: Float; T: IntType := INTEGER) : T >>>> TRUNC (r: Float; T: IntType := INTEGER) : T >>>> >>>> MAX, MIN (x,y: Ordinal) : Ordinal >>>> (x,y: Float) : Float >>>> >>>> -Relations >>>> >>>> These functions as expected for LONGINT. >>>> >>>> -Type operations >>>> >>>> ORD (element: Ordinal): Integer >>>> VAL (i: Integer; T: OrdinalType): T >>>> >>>> These function as expected, except that ORD returns INTEGER for >>>> elements of >>>> enumeration types. Otherwise, ORD returns an integer of the >>>> same base type as >>>> the element. Similarly, for VAL, if T is an enumeration type, >>>> then i must be >>>> an INTEGER. >>>> >>>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>>> >>>> ORD(n) = VAL(n, T: IntType): = n >>>> >>>> It is a static error if 'n' is not of type 'T'. >>>> >>>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) >>>> = LONGINT >>>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >>>> (A: FixedArrayType): CARDINAL >>>> (a: Array) : CARDINAL >>>> >>>> FIRST (T: OrdinalType) : BaseType(T) >>>> (T: FloatType) : T >>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>> (a: Array) : BaseType(IndexType(a)) >>>> LAST (T: OrdinalType) : BaseType(T) >>>> (T: FloatType) : T >>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>> (a: Array) : BaseType(IndexType(a)) >>>> >>>> BITSIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> BYTESIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> ADRSIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> >>>> 9. REQUIRED INTERFACES >>>> >>>> There is an additional required interface 'Long', analogous to >>>> 'Word' except that >>>> >>>> Long.T = LONGINT >>>> >>>> >>>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>>> My LONGINT implementation addresses many of your concerns. >>>>>> The LONGINT space is segregated from the INT space. I want >>>>>> to come up with an implementation that also permits ordinals >>>>>> based on LONGINT in addition to the current system of >>>>>> ordinals based on INTEGER. This requires revisiting the >>>>>> language spec and pushing through the implications. I'm >>>>>> going to look at that briefly before moving on to fixing user- >>>>>> level threading for all targets. >>>>> >>>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>>> language >>>>> definition, ordinals refers to both the above, plus INTEGER, >>>>> with CHAR and >>>>> BOOLEAN being enumerations. >>>>> >>>>> It is hard to image a use for enumerations with more than 2^32 >>>>> values. >>>>> As I recall, I was thinking this would add quite a bit of >>>>> complexity to >>>>> the language for negligible benefit. >>>>> >>>>> Subranges of LONGINT seem entirely useful and make for >>>>> consistency. >>>>> From a language definition standpoint, I think these just about >>>>> fall >>>>> into place with very little change. >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu >>>> >> From darko at darko.org Thu Jul 19 23:23:35 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 23:23:35 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: I think INT and LONG seem pretty intuitive. INT(l: LONGINT): INTEGER; LONG(i: INTEGER): LONGINT; But back on the point, range check failures are a runtime phenomena, so they are an issue at anytime. On 19/07/2007, at 10:50 PM, Tony Hosking wrote: > On Jul 19, 2007, at 4:33 PM, Darko wrote: > >> I actually favour a implicit conversion, which for this particular >> case I think would be consistent with existing M3 behaviour. > > There is no implicit conversion for floats. The danger with > implicit conversion for integers is that it would not be portable: > you would get different behavior on different machines for the same > code. Better to make the conversion explicit so that programmers > are prepared for the range check to fail. > >> >> >> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >> >>> This is a good question. I would assume that conversion must be >>> explicit to fit with the M3 philosophy. It would make sense to >>> have a conversion operation that performs the appropriate range >>> check? Any ideas for a name for the operation. >>> >>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>> >>>> Have I missed something or is there no way to assign between >>>> INTEGER and LONGINT? Is there an explicit conversion function >>>> that I've overlooked? Would assignment be so bad here since >>>> there would be an implicit range check, much like when you >>>> assign between two overlapping subranges? In a sense these two >>>> types are integer subranges of an abstract integer type >>>> containing all integers. >>>> >>>> >>>> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >>>> >>>>> Here are my notes from a run through the language spec. Next >>>>> step is to flesh out the additional bits in the compiler beyond >>>>> what I announced yesterday. I would appreciate any feedback >>>>> you can give as I look into this. >>>>> >>>>> 3. TYPES >>>>> >>>>> -Ordinal Types: >>>>> >>>>> There are three kinds of ordinal types: enumerations, >>>>> subranges, and >>>>> integers. There are two integer types, which in order of >>>>> increasing range and >>>>> precision are INTEGER and LONGINT. >>>>> >>>>> The base type of an ordinal value 'v' is its type (INTEGER or >>>>> LONGINT) if 'v' >>>>> is an integer, otherwise it is the unique enumeration type that >>>>> contains v. >>>>> >>>>> Subranges may have base type LONGINT. >>>>> >>>>> FIRST, LAST and NUMBER work for LONGINT. >>>>> >>>>> LONGINT is predeclared. >>>>> >>>>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>>>> name? LONGCARD? >>>>> >>>>> -Array Types: >>>>> >>>>> Arrays may only be indexed by ordinals having an underlying >>>>> INTEGER base type. >>>>> [Otherwise, it will be difficult deciding the index type for >>>>> open arrays.] >>>>> >>>>> -Set Types: >>>>> >>>>> It seems reasonable that SET OF Base, where the base type for >>>>> Base is LONGINT, >>>>> should be allowed. The restrictons on the number of elements >>>>> in the base set >>>>> remain (i.e., SET OF [0L..1023L] for elements having base type >>>>> LONGINT will be >>>>> practical, but not SET OF LONGINT). >>>>> >>>>> -Subtyping Rules: >>>>> >>>>> These remain the same for ordinals having LONGINT base type. >>>>> >>>>> >>>>> 4. STATEMENTS. >>>>> >>>>> -Assignment: >>>>> >>>>> Since INTEGER and LONGINT have different base types they are >>>>> not assignable. >>>>> >>>>> -For: >>>>> >>>>> FOR statements will function with LONGINT-based index types: >>>>> >>>>> FOR id := first TO last BY step DO S END >>>>> >>>>> where 'id' is an identifier, 'first' and 'last' are ordinal >>>>> expressions with >>>>> the same base type (e.g., LONGINT), step is an integer-valued >>>>> expression of >>>>> type INTEGER or LONGINT and S is a statement. If omitted >>>>> 'step' defaults to 1 >>>>> or 1L, depending on the base type of the loop bounds 'first' >>>>> and 'last'. >>>>> >>>>> If the upper bound of the loop is LAST(INTEGER) or LAST >>>>> (LONGINT), it >>>>> should be rewritten as a WHILE loop to avoid overflow. >>>>> >>>>> -Case: >>>>> >>>>> CASE statements may take an expression whose type is an ordinal >>>>> type with base >>>>> type LONGINT. >>>>> >>>>> -Inc and Dec: >>>>> >>>>> INC and DEC function for both INTEGER-based and LONGINT-based >>>>> ordinals. >>>>> >>>>> 7. EXPRESSIONS >>>>> >>>>> -Conventions for describing operations: >>>>> >>>>> The class 'Integer' will be used to describe the type class >>>>> consisting of both >>>>> INTEGER and LONGINT (similar to the use of 'Float'). >>>>> >>>>> -Numeric literals: >>>>> >>>>> Numeric literals denote constant non-negative integers or >>>>> reals. The types of >>>>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>>>> >>>>> A literal LONGINT has the same form as a literal INTEGER, >>>>> except that it is >>>>> suffixed with the character 'L'. Thus the LONGINT having value >>>>> zero would be >>>>> written '0L'. Moreover, if no explicit base is present, the >>>>> value of the >>>>> literal must be at most LAST(LONGINT). If an explicit base is >>>>> present, the >>>>> value of the literal must be less than '2^Long.Size', and its >>>>> interpretation >>>>> uses the convention of the 'Long' interface. >>>>> >>>>> -Arithmetic operations: >>>>> >>>>> We adjust the arithmetic operations as follows, where the type >>>>> class 'Integer' >>>>> can be one of INTEGER or LONGINT, FloatType represents the type >>>>> of a type >>>>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>>>> and IntType >>>>> represents the type of a type variable taking one of the values >>>>> INTEGER or LONGINT. >>>>> >>>>> prefix + (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> infix + (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> prefix - (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> infix - (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix * (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix / (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix DIV (x,y: Integer): Integer >>>>> >>>>> infix MOD (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> >>>>> ABS (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> FLOAT (x: Integer; T: FloatType := REAL): T >>>>> (x: Float; T: FloatType := REAL): T >>>>> >>>>> FLOOR (x: Float; T: IntType := INTEGER) : T >>>>> CEILING (x: Float; T: IntType := INTEGER) : T >>>>> >>>>> ROUND (r: Float; T: IntType := INTEGER) : T >>>>> TRUNC (r: Float; T: IntType := INTEGER) : T >>>>> >>>>> MAX, MIN (x,y: Ordinal) : Ordinal >>>>> (x,y: Float) : Float >>>>> >>>>> -Relations >>>>> >>>>> These functions as expected for LONGINT. >>>>> >>>>> -Type operations >>>>> >>>>> ORD (element: Ordinal): Integer >>>>> VAL (i: Integer; T: OrdinalType): T >>>>> >>>>> These function as expected, except that ORD returns INTEGER for >>>>> elements of >>>>> enumeration types. Otherwise, ORD returns an integer of the >>>>> same base type as >>>>> the element. Similarly, for VAL, if T is an enumeration type, >>>>> then i must be >>>>> an INTEGER. >>>>> >>>>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>>>> >>>>> ORD(n) = VAL(n, T: IntType): = n >>>>> >>>>> It is a static error if 'n' is not of type 'T'. >>>>> >>>>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType >>>>> (T) = LONGINT >>>>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = >>>>> LONGINT >>>>> (A: FixedArrayType): CARDINAL >>>>> (a: Array) : CARDINAL >>>>> >>>>> FIRST (T: OrdinalType) : BaseType(T) >>>>> (T: FloatType) : T >>>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>>> (a: Array) : BaseType(IndexType(a)) >>>>> LAST (T: OrdinalType) : BaseType(T) >>>>> (T: FloatType) : T >>>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>>> (a: Array) : BaseType(IndexType(a)) >>>>> >>>>> BITSIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> BYTESIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> ADRSIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> >>>>> 9. REQUIRED INTERFACES >>>>> >>>>> There is an additional required interface 'Long', analogous to >>>>> 'Word' except that >>>>> >>>>> Long.T = LONGINT >>>>> >>>>> >>>>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>>>> >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>>> My LONGINT implementation addresses many of your concerns. >>>>>>> The LONGINT space is segregated from the INT space. I want >>>>>>> to come up with an implementation that also permits ordinals >>>>>>> based on LONGINT in addition to the current system of >>>>>>> ordinals based on INTEGER. This requires revisiting the >>>>>>> language spec and pushing through the implications. I'm >>>>>>> going to look at that briefly before moving on to fixing >>>>>>> user-level threading for all targets. >>>>>> >>>>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>>>> language >>>>>> definition, ordinals refers to both the above, plus INTEGER, >>>>>> with CHAR and >>>>>> BOOLEAN being enumerations. >>>>>> >>>>>> It is hard to image a use for enumerations with more than 2^32 >>>>>> values. >>>>>> As I recall, I was thinking this would add quite a bit of >>>>>> complexity to >>>>>> the language for negligible benefit. >>>>>> >>>>>> Subranges of LONGINT seem entirely useful and make for >>>>>> consistency. >>>>>> From a language definition standpoint, I think these just >>>>>> about fall >>>>>> into place with very little change. >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------- >>>>>> Rodney M. Bates, retired assistant professor >>>>>> Dept. of Computer Science, Wichita State University >>>>>> Wichita, KS 67260-0083 >>>>>> 316-978-3922 >>>>>> rodney.bates at wichita.edu >>>>> >>> > From rodney.bates at wichita.edu Thu Jul 19 23:33:28 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 16:33:28 -0500 Subject: [M3devel] LONGINT In-Reply-To: <469F7BAD.1E75.00D7.1@scires.com> References: <469F7BAD.1E75.00D7.1@scires.com> Message-ID: <469FD8A8.8070807@wichita.edu> Randy Coleburn wrote: > Tony: > > I'd like to better understand the implications of your change as I do > use LONGINT as an index in some applications. Do you have arrays that need 64-bit subscripts on a 32-bit machine? Allow me the common assumption that both integers and addresses have the native word size on most machines. In this case, most arrays that need 64-bit subscripts would exceed the virtual address space of the machine. Exceptions would require elements of size at most a byte, and overall sizes in excess of half the virtual address space. Even PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the virtual space before 32-bit subscripts ran out. All this seems pretty unlikely. I would favor keeping INTEGER as the type of open array subscripts and not allowing LONGINT to be a fixed array subscript type. It saves a whole lot of language complexity, and doesn't disallow much. If it really mattered, you could still use unsafe techniques for such memory-hogging arrays. This might be a reason to extend unsafe arithmetic on ADDRESS to accept LONGINT second operands. This is actually consistent with the rest of the operator generalizations. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From darko at darko.org Thu Jul 19 23:35:23 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 23:35:23 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FD59A.8020809@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FD59A.8020809@wichita.edu> Message-ID: <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> I agree with you and I strongly agree with Tony's approach to the implementation where the two integer types are not subtypes. The VAL usage would be a bit finicky given how often this would be done in practice, something more concise (like INT and LONG) would be better. On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote: > In my original 64-bit proposal, I made INTEGER # LONGINT, and also > the two > types have no subtype relation (which, I think is what Antony is > saying). > It avoids having a lot of things happen implicitly from other rules > in the > language. > > But then I added a separate rule that these two types and their > subranges > are mutually assignable, subject to the existing assignability > rules that > now apply to a type and its subranges. Namely the RHS value must be > in the > range of the of the LHS type, which sometimes has to be checked at > runtime. > > This allows assignment without explicit conversion, as well as many > other > things, for example, VALUE parameter passing, that require > assignability. > This is consistent with the existing rules for assignments involving > different subranges. > > For explicit conversions (which are probably needed somewhere anyway, > even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit > the existing language well. For consistency, it seems good to allow > ORD(LongIntArg), which is an alternative conversion in one direction. > It may seem unnecessary, but it's not as useless as ORD(IntegerArg), > which we already have. Actually, these extensions of VAL and ORD > fall out of the existing definitions, when LONGINT is an ordinal type. > > Darko wrote: >> I actually favour a implicit conversion, which for this >> particular case I think would be consistent with existing M3 >> behaviour. >> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >>> This is a good question. I would assume that conversion must be >>> explicit to fit with the M3 philosophy. It would make sense to >>> have a conversion operation that performs the appropriate range >>> check? Any ideas for a name for the operation. >>> >>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>> >>>> Have I missed something or is there no way to assign between >>>> INTEGER and LONGINT? Is there an explicit conversion function >>>> that I've overlooked? Would assignment be so bad here since >>>> there would be an implicit range check, much like when you >>>> assign between two overlapping subranges? In a sense these two >>>> types are integer subranges of an abstract integer type >>>> containing all integers. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From darko at darko.org Fri Jul 20 00:02:55 2007 From: darko at darko.org (Darko) Date: Fri, 20 Jul 2007 00:02:55 +0200 Subject: [M3devel] LONGINT In-Reply-To: <469FD8A8.8070807@wichita.edu> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> Message-ID: <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> I think in 64 bit land you get a variety of combinations and possibly the most common is a 32 bit address space with 64 bit integers, since applications seldom need to operate in the larger address space. But I would think it you wouldn't allocate an object bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would be more likely. The only situation where I can think of where this is an issue is using a long integer index in an array of integer proportions, you could handle this using arithmetic, also illustrates where you'd need an implicit conversion: CONST start = 2^63-500; end = 2^63-200; VAR a: ARRAY[0..start-end+1] OF CHAR; BEGIN FOR i := start TO end DO a[INT(i-start)] := 'x' END; Or you could rule that all arrays are of INTEGER size, but may have a LONGINT index. Open arrays would always be integers. This would probably be messy to implement and NUMBER would have a different base to FIRST and LAST. That doesn't sound very good. On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote: > > > Randy Coleburn wrote: >> Tony: >> I'd like to better understand the implications of your change as >> I do use LONGINT as an index in some applications. > > Do you have arrays that need 64-bit subscripts on a 32-bit machine? > > Allow me the common assumption that both integers and addresses have > the native word size on most machines. In this case, most arrays that > need 64-bit subscripts would exceed the virtual address space of the > machine. Exceptions would require elements of size at most a byte, > and overall sizes in excess of half the virtual address space. Even > PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the > virtual space before 32-bit subscripts ran out. All this seems pretty > unlikely. > > I would favor keeping INTEGER as the type of open array subscripts > and not allowing LONGINT to be a fixed array subscript type. It > saves a whole lot of language complexity, and doesn't disallow much. > > If it really mattered, you could still use unsafe techniques for > such memory-hogging arrays. This might be a reason to extend unsafe > arithmetic on ADDRESS to accept LONGINT second operands. This is > actually consistent with the rest of the operator generalizations. >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Jul 20 00:04:14 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 17:04:14 -0500 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: <469FDFDE.9020201@wichita.edu> Tony Hosking wrote: > On Jul 19, 2007, at 4:33 PM, Darko wrote: > >> I actually favour a implicit conversion, which for this particular >> case I think would be consistent with existing M3 behaviour. > > > There is no implicit conversion for floats. The danger with implicit > conversion for integers is that it would not be portable: you would get > different behavior on different machines for the same code. Better to > make the conversion explicit so that programmers are prepared for the > range check to fail. But is this argument any stronger for requiring explicit conversions for INTEGER/LONGINT assignments than for assigning to subranges? Many assignments in the language now, without any type conversion, admit the possibility of RT range errors. And these can be dependent on the size of INTEGER too. Consider: VAR V : [ 0 .. 65535 ] ; VAR I : CARDINAL ; ... V := I DIV 2 ; I think for portability, the principle that the static semantics should be the same for all sizes of INTEGER (and LONGINT too) is as much as we can hope for. Certainly, there are already countless ways the integer size can change the dynamic semantics of a program. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From darko at darko.org Thu Jul 19 20:41:08 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 20:41:08 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> This really is great stuff Tony, thanks for doing the hard yards. Will you be making a build of this available in your usual spot? I'd like to try this out for a while and look for creative ways to make it break (no offence intended) and get a feel for where it needs to be extended. In the spirit of the M3 founding fathers, I think we need some experience with this and then look at the simplest and smallest change we can do to support what is missing. Cheers, Darko. On 19/07/2007, at 5:31 PM, Tony Hosking wrote: > My LONGINT implementation addresses many of your concerns. The > LONGINT space is segregated from the INT space. I want to come up > with an implementation that also permits ordinals based on LONGINT > in addition to the current system of ordinals based on INTEGER. > This requires revisiting the language spec and pushing through the > implications. I'm going to look at that briefly before moving on > to fixing user-level threading for all targets. > > On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: > >> Hello everyone, >> >> I have read the various proposals for supporting integers of >> different >> bit sizes and am getting a little worried that they are running >> away from the traditional Modula-3 simplicity. As far as I know, >> there is very little in Modula-3 that depends on the actual size >> in bits of INTEGERs and CARDINALs. It doesn't seem to me to make >> much sense to introduce types like Int32.T and Int64.T and then >> make the definition Int32.T = INTEGER (on one platform) and Int64.T >> = INTEGER (on another platform). I'm wondering if it would instead >> be possible to introduce a new group of types in the sense that >> Modula-3 now has integer types and floating-point types, and call >> these types "fixed width" or "specified width" types. Conversions >> between these types and INTEGER or CARDINAL would have to be done >> using functions (operators) that are the analogs of FLOAT, ROUND, >> etc. Standard arithmetic operators would be overloaded just like >> they are today for integers and floating-point numbers. Am I just >> duplicating someone else's proposal here? Perhaps this proposal >> doesn't address everything one might want to do with these extended- >> size types? >> >> Maybe I am just dreaming about getting Modula-3 running on a >> DECsystem-20 with 36-bit integers...with pickles that are >> interchangeable >> with i386 pickles, of course. >> >> What do people want to do with these extended-size types anyhow? >> It seems good to me that INTEGER is the largest type that I can >> expect my processor to calculate efficiently with. I would use >> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible >> and write my code to be flexible about the BYTE/BITSIZE... but OK, >> I can see the rationale for hiding all this in the compiler (and >> inlining everything) in the few cases where I might want four- >> function >> arithmetic on (specifically) 64- or 128-bit integers. >> >> Mika >> >> Darko writes: >>> Actually I stated the wrong reason for that one, it's really an >>> argument against mixed integer assignment. >>> >>> And saying that it looks right from the C/C++ point of view is >>> pretty >>> damning... >>> >>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >>> >>>> Mail from unsubscribed address forwarded to the list... >>>> ---------------------------- Original Message >>>> ---------------------------- >>>> Subject: Re: A nonnative 64-bit language proposal >>>> From: hendrik at topoi.pooq.com >>>> Date: Wed, October 25, 2006 14:22 >>>> To: m3devel at elegosoft.com >>>> ------------------------------------------------------------------- >>>> --- >>>> ---- >>>> >>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>>> >>>>> For your example to compute as an integer even if that >>>>> overflows and >>>>> it wouldn't as a longint seems right from my C/C++ point of view. >>>> >>>> I've always thought C/C++ were badly wrong on this one, even >>>> from their own archaic low-level machine-oriented viewpoint. >>>> Most computers have integer multiply instructions that return a >>>> double-length product. >>>> >>>> -- hendrik >>>> >>>> > From darko at darko.org Fri Jul 20 04:49:08 2007 From: darko at darko.org (Darko) Date: Fri, 20 Jul 2007 04:49:08 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FD59A.8020809@wichita.edu> <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> Message-ID: <9A8114D3-DD14-459E-A423-DA1947A15235@darko.org> On the other side of the ledger, the fact that the following overflows is pretty unpleasant: CONST big = 2^32-1; VAR i: LONGINT; BEGIN i := big * big; On 19/07/2007, at 11:35 PM, Darko wrote: > I agree with you and I strongly agree with Tony's approach to the > implementation where the two integer types are not subtypes. > > The VAL usage would be a bit finicky given how often this would be > done in practice, something more concise (like INT and LONG) would > be better. > > > On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote: > >> In my original 64-bit proposal, I made INTEGER # LONGINT, and also >> the two >> types have no subtype relation (which, I think is what Antony is >> saying). >> It avoids having a lot of things happen implicitly from other >> rules in the >> language. >> >> But then I added a separate rule that these two types and their >> subranges >> are mutually assignable, subject to the existing assignability >> rules that >> now apply to a type and its subranges. Namely the RHS value must >> be in the >> range of the of the LHS type, which sometimes has to be checked at >> runtime. >> >> This allows assignment without explicit conversion, as well as >> many other >> things, for example, VALUE parameter passing, that require >> assignability. >> This is consistent with the existing rules for assignments involving >> different subranges. >> >> For explicit conversions (which are probably needed somewhere anyway, >> even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit >> the existing language well. For consistency, it seems good to allow >> ORD(LongIntArg), which is an alternative conversion in one direction. >> It may seem unnecessary, but it's not as useless as ORD(IntegerArg), >> which we already have. Actually, these extensions of VAL and ORD >> fall out of the existing definitions, when LONGINT is an ordinal >> type. >> >> Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >>> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >>>> This is a good question. I would assume that conversion must >>>> be explicit to fit with the M3 philosophy. It would make sense >>>> to have a conversion operation that performs the appropriate >>>> range check? Any ideas for a name for the operation. >>>> >>>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>>> >>>>> Have I missed something or is there no way to assign between >>>>> INTEGER and LONGINT? Is there an explicit conversion function >>>>> that I've overlooked? Would assignment be so bad here since >>>>> there would be an implicit range check, much like when you >>>>> assign between two overlapping subranges? In a sense these two >>>>> types are integer subranges of an abstract integer type >>>>> containing all integers. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > From mika at async.caltech.edu Fri Jul 20 09:16:09 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Jul 2007 00:16:09 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Thu, 19 Jul 2007 11:27:48 EDT." Message-ID: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> Hi again Tony, I am wondering, is it at all possible you might have to compile the new compiler with itself to get it to generate the proper code? I was at first able to get Juno to crash: *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/JunoRT.m3", line 698 *** but after recompiling a second time, it no longer seems to do that. By the way, I am somewhat suspicious that this Juno crash has something to do with threading: if you look closely, that part of Juno has to do with thread switching into and out of the Juno-machine...which is why I was happy to see it disappear (however it did that). I still have a threading crash in mentor. I run "Wheeler" to get this one... gdb /usr/local/cm3/bin/mentor GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .......................................... done (gdb) run Starting program: /usr/local/cm3/bin/mentor Reading symbols for shared libraries .++++++++++++++++++++.++++++++++++++++++ done *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675 *** Program exited with code 01. (gdb) where No stack. (gdb) cvs status ./m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3 =================================================================== File: ThreadPThread.m3 Status: Up-to-date Working revision: 1.34 Repository revision: 1.34 /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v Commit Identifier: GYzMl9TO92Eakoqs Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) [QT:~/cm3] mika% OS: 10.4 / ppc (My 10.3 machine is in for service at the moment.) Also the Bresenham demo just dies for me now, but that could of course be a bug in mentor. It was working great the other day.. not sure what happened there. I really don't think it's my old system that's corrupting the new images, but I am *never* 100% certain of that. I found a very weird behavior with the build system, actually. I found that the not-yet-installed compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in /usr/local/cm3/bin, but *only* if that is in the shell PATH. Is that a known/desired behavior? It causes the brand new compiler to use the old cm3.cfg, and it does so quietly without any warnings or messages whatsoever. Changing your PATH makes it stop do that and instead crash, prompting me to put the cm3.cfg I want in the right place... Mika P.S. I agree with you that 8000 threads is ample and good going for pthreads. Tony Hosking writes: >Mika, > >I have diagnosed and fixed the problems you were seeing with thread >pausing and alerts. mentor no longer exhibits the bug you reported >and diagnosed. Thanks! I am starting to feel much more confident >about the threads subsystem now that I am able to run mentor's >functionality without problems on my Darwin 10.4.10 system using >pthreads. There are still the capacity problems (number of pthreads >beyond 8000) on Darwin, but that is a system issue not a problem with >the pthreads implementation. For large numbers of threads the user- >level implementation still seems the way to go. I want to update >that to use getcontext/setcontext ASAP so that it will function again >on platforms that have implemented secure (encrypting) versions of >setjmp/longjmp that prevent stack hacks like those used to implement >the current user-level threads system. Thanks again for your help, >and please let me know of any further issues. > >-- Tony > >On Jul 17, 2007, at 3:31 AM, Mika Nystrom wrote: > >> Hi Tony, >> >> I have a friend with a 10.4.10 system, >> >> Darwin QT.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 >> 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh >> powerpc >> >> I used your instructions again, installing from the CVS head. You're >> right, things are different on this OS! The programs that were >> taking 100% cpu (mine as well as the ones in the distribution) on >> my 10.3 system are not doing that on the the 10.4 system. ktok >> still crashes, now sometimes with an illegal instruction, sometimes >> at line 2310, as before. >> >> After some fiddling, during which mentor worked far better than on >> 10.3, I was able to get mentor to---as it appears---deadlock. The >> Bresenham demo seems to deadlock mentor pretty reliably for me. >> Here's a traceback from hitting ctrl-C after mentor has gone >> catatonic: >> >> (gdb) where >> #0 0x9002c3c8 in semaphore_wait_signal_trap () >> #1 0x90030eac in pthread_cond_wait () >> #2 0x01d2d83c in ThreadPThread__InnerWait (M3_AYIbX3_m=0x2860540, >> M3_Bl0jv4_c=0x2a43b24, M3_BXP32l_self=0x2860014) at >> ThreadPThread.m3:212 >> #3 0x01d2dc6c in Thread__Wait (M3_AYIbX3_m=0x2860540, >> M3_Bl0jv4_c=0x2a43b24) at ThreadPThread.m3:251 >> #4 0x018991d8 in Trestle__AwaitDelete (M3_BFdKo9_v=0x2a0a9cc) at >> Trestle.m3:884 >> #5 0x0120b058 in ZeusPanel__Interact (M3_Bd56fi_title=0x36ace0, >> M3_DYb95R_path=0x2863f94) at ZeusPanel.m3:477 >> #6 0x0028af0c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:165 >> #7 0x01d16654 in RTLinker__RunMainBody (M3_DjPxE3_m=0x2b1428) at >> RTLinker.m3:399 >> #8 0x01d15418 in RTLinker__AddUnitI (M3_DjPxE3_m=0x2b1428) at >> RTLinker.m3:113 >> #9 0x01d15514 in RTLinker__AddUnit (M3_DjPxE5_b=0x28ae88) at >> RTLinker.m3:122 >> #10 0x00002a44 in main (argc=1, argv=0xbffffc98, envp=0xbffffca0) >> at _m3main.mc:4 >> >> My program that was having trouble with pickles now does the >> following. It is reading data out of a disk file that it has >> recently written using Pickle.Write. I'm afraid I can't give out >> the source code for this program, so I'll have to isolate a simpler >> case. Btw, this happens also with @M3nogc. No UNSAFE code of any >> kind involved here. Attempting to access the arguments of Text.Equal >> through gdb crashes gdb with a bus error. If someone has an idea >> (even a vague one) what might be the problem I could spend some >> time poking around the code... >> >> ((1)) FIXPersistentState.Init: initialized tbl backed by "states/ >> asdfw_25fwds.snt" >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 >> 0x900031c8 in strlen () >> (gdb) where >> #0 0x900031c8 in strlen () >> #1 0x01671c70 in Text8CString__GetInfo (M3_A8R5P5_t=0x1fb17f8, >> M3_BUgnwf_info=0xbfffe4bc) at Text8CString.m3:23 >> #2 0x0166dbd4 in Text__Equal (M3_Bd56fi_t=0x1fb17f8, >> M3_Bd56fi_u=0x1f9322c) at Text.m3:31 >> #3 0x003a8fd0 in FIXEngine__SanityCheckFields >> (M3_EdNxIG_t=0x1f953b0, M3_Ck0t2u_msg=0x1fb177c) at FIXEngine.m3:259 >> #4 0x003aad58 in FIXEngine__InitSession (M3_EdNxIG_t=0x1f953b0, >> M3_CVvbAZ_session=0x1f93290) at FIXEngine.m3:450 >> #5 0x003a9ad4 in FIXEngine__Init (M3_EdNxIG_t=0x1f953b0, >> M3_Cbj6ab_conn=0x1f95454, M3_CqtnCQ_mode=0 '\0', >> M3_Cwb5VA_heartBtInt=, M3_CVvbAZ_session=0x1f93290, >> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', >> M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=> 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=, >> M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Fri Jul 20 17:42:27 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 11:42:27 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> References: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> Message-ID: <066BF1FB-7815-4761-A04F-ED68A75564A5@cs.purdue.edu> 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=, M3_CVvbAZ_session=0x1f93290, >>> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', >>> M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=>> 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=, >>> M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Fri Jul 20 22:47:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 16:47:45 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FDFDE.9020201@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FDFDE.9020201@wichita.edu> Message-ID: <05CD4EBC-E1C6-4BB7-919C-8032B5265609@cs.purdue.edu> I think I am coming around to Rodney's position. We should consider INTEGER and LONGINT assignable under the current rules for subranges. Thus, INTEGER := LONGINT will cause a range check (and underlying conversion of the integer value from BITSIZE(LONGINT) to BITSIZE(INTEGER)), whereas LONGINT := INTEGER will need not check (though the conversion will be necessary to extend sign as expected). I believe this functionality can easily be implemented in the current compiler. Also, I am willing to allow indexing of arrays using LONGINT-based ordinals for the index type. The usual restrictions on array size will obtain, and zero-based array indexes will be computed into integer offsets. Thus, for an array indexed [minL..maxL] where minL and maxL have base type LONGINT, the offset will be computed as: index - minL and converted to an INTEGER value to index the array. Because of the sizing restriction, index - minL must be expressible as an INTEGER. Here are my revised notes: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longint.txt URL: -------------- next part -------------- On Jul 19, 2007, at 6:04 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> On Jul 19, 2007, at 4:33 PM, Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >> There is no implicit conversion for floats. The danger with >> implicit conversion for integers is that it would not be >> portable: you would get different behavior on different machines >> for the same code. Better to make the conversion explicit so >> that programmers are prepared for the range check to fail. > > But is this argument any stronger for requiring explicit conversions > for INTEGER/LONGINT assignments than for assigning to subranges? > Many assignments in the language now, without any type conversion, > admit the possibility of RT range errors. And these can be dependent > on the size of INTEGER too. Consider: > > VAR V : [ 0 .. 65535 ] ; > VAR I : CARDINAL ; > ... > V := I DIV 2 ; > > I think for portability, the principle that the static semantics > should be > the same for all sizes of INTEGER (and LONGINT too) is as much as > we can > hope for. Certainly, there are already countless ways the integer > size can > change the dynamic semantics of a program. > > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From mika at async.caltech.edu Sun Jul 22 14:12:07 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Jul 2007 05:12:07 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Fri, 20 Jul 2007 11:42:27 EDT." <066BF1FB-7815-4761-A04F-ED68A75564A5@cs.purdue.edu> Message-ID: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Tony Hosking writes: ... >> 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 *obsessively* clean my directories between builds! I have double- and triple-checked that nothing in the source tree is left in object form after doing do-cm3-std.sh realclean do-cm3-core.sh realclean Yet, this happens. My best guess is that somehow, old objects (from /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. Surely that's not supposed to happen? Why does it happen to me and apparently not to you? I follow your directions exactly and always start from an absolutely clean system (on Mac I don't even have PM3 installed, so there's no Modula-3 at all before I start following the instructions). >> I still have a threading crash in mentor. I run "Wheeler" to get this >> one... >> ... >> >> *** >> *** 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. Debugging this a bit further, I think I'm just running out of stack space. You are saying that this call can fail because of too small a requested stack space, too? It might be nice to have some sort of error message here instead of just an assert failure... How big is your stack limit on your mac? On mine it's 64 megabytes, and when I added some printing: RTIO.PutText("Upthread.attr_getstacksize returned bytes="); RTIO.PutInt(bytes); RTIO.PutText(" defaultStackSize="); RTIO.PutInt(defaultStackSize); RTIO.PutChar('\n'); bytes := MAX(bytes, size * ADRSIZE(Word.T)); WITH r = Upthread.attr_setstacksize(attr, bytes) DO IF r # 0 THEN RTIO.PutText("Upthread.attr_setstacksize failed, size="); ELSE RTIO.PutText("Upthread.attr_setstacksize succeeded, size="); END; RTIO.PutInt(size); RTIO.PutText(" bytes="); RTIO.PutInt(bytes); RTIO.PutChar('\n'); <*ASSERT r=0*> END; RTIO.Flush(); I found the following: (running Wheeler) ... lots of times ... Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 Upthread.attr_getstacksize returned bytes=524288 defaultStackSize=79632 Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 Upthread.attr_getstacksize returned bytes=524288 defaultStackSize=79632 Upthread.attr_setstacksize failed, size=637056 bytes=2548224 *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 *** Program exited with code 01. It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize for another 64 kilowords , and WheelerCompressObliqView.m3 requests 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads and I just run out of stack space. (I am assuming that pthreads allocates stacks in the 'stack' segment of the process...) Attempting to fix the bug in mentor makes it run out of stack space, looks like it's some recursive descent parser... Maybe this demo just won't run on my computer. >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 was able to get it to run again. And deadlock again. And run again... it's definitely something intermittent. I think it happens right when it attempts to start the threads, not afterwards. And when you ctrl-C it, all you get is that it's stopped in Trestle__AwaitDelete (I already sent this one). > >> 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. > Here's what I'm doing... I install cm3-5.4.0 from the elegosoft site using that package's cminstall. This installs a cm3.cfg. Then I follow your directions for bootstrapping from the CVS head. At some point, those directions say to switch from using the original compiler to the newly compiled compiler. Now, when you switch to the newly compiled compiler, the only cm3.cfg in the system is the one from the bootstrappING compiler, that is, the 5.4.0 release cm3.cfg. What happens is the following: 1. If my shell PATH includes the path to the old cm3, the new compiler (silently) finds the old cm3.cfg and uses it. 2. If my shell PATH does not include the path to the old cm3, the new compiler does not find the old cm3.cfg. This behavior will easily trip someone up who's trying to bootstrap cm3, because I don't think any of the scripts (or bootstrapping directions) do anything whatever to make sure that the new compiler gets a new cm3.cfg. What I've taken to doing is taking cm3 out of my PATH permanently so that I always have to type the full path. That way I can't get a compiler-cfg mismatch, because the new compiler will refuse to work until I have provided it with a new cm3.cfg. I've been doing this for the last several bootstraps. Mika From hosking at cs.purdue.edu Sun Jul 22 17:16:10 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 22 Jul 2007 11:16:10 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> References: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: Hi Mika, Thanks for all of your useful feedback. My replies below... On Jul 22, 2007, at 8:12 AM, Mika Nystrom wrote: > > Tony Hosking writes: > ... >>> 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 *obsessively* clean my directories between builds! I have double- > and triple-checked that nothing in the source tree is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, old objects (from > /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. > Surely that's not supposed to happen? Why does it happen to me and > apparently not to you? I follow your directions exactly and always > start from an absolutely clean system (on Mac I don't even have PM3 > installed, so there's no Modula-3 at all before I start following > the instructions). I'm not trying to imply that you are doing anything wrong -- just wanting to make sure that we isolate the problem carefully in order to diagnose it. As I have mentioned in the past, I hand-build my bootstrap compilers, avoiding using the scripts, since the order of package builds can vary depending on which parts of the runtime and compiler subsystems have been changed. I only use the do-cm3-std.sh script once I am sure I have a functional compiler. Have you managed to reproduce the error from before? > > >>> I still have a threading crash in mentor. I run "Wheeler" to get >>> this >>> one... >>> > ... >>> >>> *** >>> *** 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. > > Debugging this a bit further, I think I'm just running out of stack > space. You are saying that this call can fail because of too small > a requested stack space, too? It might be nice to have some sort > of error message here instead of just an assert failure... Yes, that's why I think it may be better to try pthread_attr_setstacksize without checking the return value. Better to ignore a bad sized closure's request for a particular size than to crash and burn. > > How big is your stack limit on your mac? On mine it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize succeeded, > size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize > for another 64 kilowords , and WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads > and I just run out of stack space. (I am assuming that pthreads > allocates stacks in the 'stack' segment of the process...) Yes, that is probably the case. > > Attempting to fix the bug in mentor makes it run out of stack space, > looks like it's some recursive descent parser... Maybe this demo > just won't run on my computer. This is troubling. Perhaps we should more explicitly allocate stacks from the heap so as to avoid this issue. I can look into this. > >> 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 was able to get it to run again. And deadlock again. And run > again... it's definitely something intermittent. I think it happens > right when it attempts to start the threads, not afterwards. > > And when you ctrl-C it, all you get is that it's stopped > in Trestle__AwaitDelete (I already sent this one). Hmm. More food for thought. >>> 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. >> > > Here's what I'm doing... > > I install cm3-5.4.0 from the elegosoft site using that package's > cminstall. This installs a cm3.cfg. > > Then I follow your directions for bootstrapping from the CVS head. > At some point, those directions say to switch from using the original > compiler to the newly compiled compiler. > > Now, when you switch to the newly compiled compiler, the only cm3.cfg > in the system is the one from the bootstrappING compiler, that is, the > 5.4.0 release cm3.cfg. What happens is the following: > > 1. If my shell PATH includes the path to the old cm3, the new compiler > (silently) finds the old cm3.cfg and uses it. > > 2. If my shell PATH does not include the path to the old cm3, the new > compiler does not find the old cm3.cfg. > > This behavior will easily trip someone up who's trying to bootstrap > cm3, because I don't think any of the scripts (or bootstrapping > directions) do anything whatever to make sure that the new compiler > gets a new cm3.cfg. What I've taken to doing is taking cm3 out of > my PATH permanently so that I always have to type the full path. > That way I can't get a compiler-cfg mismatch, because the new compiler > will refuse to work until I have provided it with a new cm3.cfg. > I've been doing this for the last several bootstraps. Yes, I think this is a problem. I have never used the CM3 install scripts, since I am in bootstrapping mode almost all the time as part of the development cycle, so I am always using the same cm3.cfg. I think your strategy is a good one for bootstrapping with a cminstall system present. > > > Mika From dabenavidesd at yahoo.es Sun Jul 22 21:31:42 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Jul 2007 21:31:42 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: <487036.69680.qm@web27110.mail.ukl.yahoo.com> Hi: What I have saw of the two step boostrapping process is that cm3 executable looks in its own directory for cm3.cfg, so I have made a copy from /usr/local/cm3/bin to /usr/local/cm3/pkg/cm3/LINUXLIBC6 Another thing is that do-cm3-std.sh realclean, doesnt clean some m3core parts, some yes. Thanks --- Mika Nystrom wrote: > > Tony Hosking writes: > ... > >> 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 *obsessively* clean my directories between builds! > I have double- > and triple-checked that nothing in the source tree > is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, > old objects (from > /usr/local/cm3/pkg?) are "leaking" through the > bootstrapping process. > Surely that's not supposed to happen? Why does it > happen to me and > apparently not to you? I follow your directions > exactly and always > start from an absolutely clean system (on Mac I > don't even have PM3 > installed, so there's no Modula-3 at all before I > start following > the instructions). > > > >> I still have a threading crash in mentor. I run > "Wheeler" to get this > >> one... > >> > ... > >> > >> *** > >> *** 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. > > Debugging this a bit further, I think I'm just > running out of stack > space. You are saying that this call can fail > because of too small > a requested stack space, too? It might be nice to > have some sort > of error message here instead of just an assert > failure... > > How big is your stack limit on your mac? On mine > it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize > returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, > bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize > failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize > succeeded, size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 > bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 > bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 > bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls > IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls > IncDefaultStackSize > for another 64 kilowords , and > WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of > those threads > and I just run out of stack space. (I am assuming > that pthreads > allocates stacks in the 'stack' segment of the > process...) > > Attempting to fix the bug in mentor makes it run out > of stack space, > looks like it's some recursive descent parser... > Maybe this demo > just won't run on my computer. > > >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 was able to get it to run again. And deadlock > again. And run > again... it's definitely something intermittent. I > think it happens > right when it attempts to start the threads, not > afterwards. > > And when you ctrl-C it, all you get is that it's > stopped > in Trestle__AwaitDelete (I already sent this one). > > > > >> 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, > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Mon Jul 23 09:29:41 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Jul 2007 09:29:41 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <487036.69680.qm@web27110.mail.ukl.yahoo.com> Message-ID: <412757.94770.qm@web27109.mail.ukl.yahoo.com> Hi, Actually the existing directories on m3-sys after execution of scripts/do-cm3-std.sh buildship: m3linker m3front cm3 On the These packages are not listed when that script inits I guess these packages are not necessary when boostrapping cm3 without steps. Executing scripts/do-cm3-core.sh realclean does that cleans. Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > What I have saw of the two step boostrapping process > is that cm3 executable looks in its own directory > for > cm3.cfg, so I have made a copy from > /usr/local/cm3/bin > to /usr/local/cm3/pkg/cm3/LINUXLIBC6 > > Another thing is that do-cm3-std.sh realclean, > doesnt > clean some m3core parts, some yes. > > > Thanks > > --- Mika Nystrom wrote: > > > > > Tony Hosking writes: > > ... > > >> 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 *obsessively* clean my directories between > builds! > > I have double- > > and triple-checked that nothing in the source tree > > is left in object > > form after doing > > > > do-cm3-std.sh realclean > > do-cm3-core.sh realclean > > > > Yet, this happens. My best guess is that somehow, > > old objects (from > > /usr/local/cm3/pkg?) are "leaking" through the > > bootstrapping process. > > Surely that's not supposed to happen? Why does it > > happen to me and > > apparently not to you? I follow your directions > > exactly and always > > start from an absolutely clean system (on Mac I > > don't even have PM3 > > installed, so there's no Modula-3 at all before I > > start following > > the instructions). > > > > > > >> I still have a threading crash in mentor. I > run > > "Wheeler" to get this > > >> one... > > >> > > ... > > >> > > >> *** > > >> *** 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. > > > > Debugging this a bit further, I think I'm just > > running out of stack > > space. You are saying that this call can fail > > because of too small > > a requested stack space, too? It might be nice to > > have some sort > > of error message here instead of just an assert > > failure... > > > > How big is your stack limit on your mac? On mine > > it's 64 megabytes, > > and when I added some printing: > > > > RTIO.PutText("Upthread.attr_getstacksize > > returned bytes="); > > RTIO.PutInt(bytes); > > RTIO.PutText(" defaultStackSize="); > > RTIO.PutInt(defaultStackSize); > > RTIO.PutChar('\n'); > > > > bytes := MAX(bytes, size * > ADRSIZE(Word.T)); > > WITH r = Upthread.attr_setstacksize(attr, > > bytes) DO > > IF r # 0 THEN > > > RTIO.PutText("Upthread.attr_setstacksize > > failed, size="); > > ELSE > > > RTIO.PutText("Upthread.attr_setstacksize > > succeeded, size="); > > END; > > RTIO.PutInt(size); > > RTIO.PutText(" bytes="); > > RTIO.PutInt(bytes); > > RTIO.PutChar('\n'); > > <*ASSERT r=0*> > > END; > > RTIO.Flush(); > > > > I found the following: > > > > (running Wheeler) > > > > ... lots of times ... > > Upthread.attr_setstacksize succeeded, size=79632 > > bytes=524288 > > Upthread.attr_getstacksize returned bytes=524288 > > defaultStackSize=79632 > > Upthread.attr_setstacksize succeeded, size=79632 > > bytes=524288 > > Upthread.attr_getstacksize returned bytes=524288 > > defaultStackSize=79632 > > Upthread.attr_setstacksize failed, size=637056 > > bytes=2548224 > > > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file > > "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > > *** > > > > > > Program exited with code 01. > > > > It's really a bug in mentor. Zeus.m3:499 calls > > IncDefaultStackSize > > to request another 10 kilowords, Obliq.m3:32 calls > > IncDefaultStackSize > > for another 64 kilowords , and > > WheelerCompressObliqView.m3 requests > > 8*GetDefaultStackSize in a SizedClosure. A bunch > of > > those threads > > and I just run out of stack space. (I am assuming > > that pthreads > > allocates stacks in the 'stack' segment of the > > process...) > > > > Attempting to fix the bug in mentor makes it run > out > > of stack space, > > looks like it's some recursive descent parser... > > Maybe this demo > > just won't run on my computer. > > > > >Weird, I was running Bresenham just fine > yesterday > > after the fix I > > >checked in. Sounds like you may have some stale > > object files lying > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From wagner at elegosoft.com Mon Jul 23 12:55:22 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Jul 2007 12:55:22 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <412757.94770.qm@web27109.mail.ukl.yahoo.com> References: <412757.94770.qm@web27109.mail.ukl.yahoo.com> Message-ID: <37913.194.138.127.36.1185188122.squirrel@mail.elegosoft.com> do-cm3-std.sh is the script that builds the complete set of usable M3 application packages after an initial CM3 installation. It has no connection to compiler bootstrapping at all. do-cm3-core.sh is a script that can be used to build a basic system without any demos or large applications, but including the compiler itself. It can usually not be used for bootstrapping the compiler either (at least on its own, as changes in supported platforms or other core units may require more elaborate build and ship schemes). The scripts were intended for the M3 end user and not for the rather special situation of language and runtime development of CM3 itself. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Mon Jul 23 15:43:37 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Jul 2007 15:43:37 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <37913.194.138.127.36.1185188122.squirrel@mail.elegosoft.com> Message-ID: <502092.9992.qm@web27110.mail.ukl.yahoo.com> Hi, actually I meant when doing the two step bootstrapping process the existing directories (TARGET) on m3-sys after execution of scripts/do-cm3-std.sh realclean are: m3linker m3front cm3 These packages are not listed when that script inits I guess these packages are not necessary when boostrapping cm3 without steps. Executing scripts/do-cm3-core.sh realclean does that cleans. Thanks --- Olaf Wagner wrote: > do-cm3-std.sh is the script that builds the complete > set of usable > M3 application packages after an initial CM3 > installation. It has > no connection to compiler bootstrapping at all. > > do-cm3-core.sh is a script that can be used to build > a basic system > without any demos or large applications, but > including the compiler > itself. It can usually not be used for > bootstrapping the compiler > either (at least on its own, as changes in > supported platforms or > other core units may require more elaborate build > and ship schemes). > > The scripts were intended for the M3 end user and > not for the rather > special situation of language and runtime > development of CM3 itself. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 > | USt-IdNr: DE163214194 > > ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From mika at async.caltech.edu Tue Jul 24 15:54:28 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 24 Jul 2007 06:54:28 -0700 Subject: [M3devel] Question about TEXTs under CM3 Message-ID: <200707241354.l6ODsSh6032994@camembert.async.caltech.edu> Hello everyone, Here's a random question that hopefully someone can answer... Is it true that certain TEXTs can't be Pickled under CM3? Unless there's some magic I don't understand going on, I am thinking that would be the implication of: UNSAFE INTERFACE Text8CString; ... TYPE T <: Public; Public = TEXT OBJECT str: Ctypes.char_star; END; (* The array contains the characters of the text followed by a '\000'. *) ... I hope someone can set me straight and tell me that no, the situation isn't as dire as that---some clever thing somewhere makes it possible to Pickle all objects of type TEXT... Mika From mika at async.caltech.edu Thu Jul 26 14:40:29 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Jul 2007 05:40:29 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Tue, 24 Jul 2007 06:54:28 PDT." <200707241354.l6ODsSh6032994@camembert.async.caltech.edu> Message-ID: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Ok, I am about to answer my own email. Here's a little program I wrote: MODULE Main; IMPORT Pickle, IO, Params, TextWr, TextRd; VAR wr := NEW(TextWr.T).init(); toPickle := "pickle this"; BEGIN IF Params.Count > 1 THEN toPickle := Params.Get(1) END; Pickle.Write(wr,toPickle); IO.Put("pickled \""&toPickle&"\"\n"); IO.Put("read back \""& Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) &"\"\n"); END Main. === On FreeBSD4 with my ancient, creaky PM3: (64)trs80:~/ptest/src>../FreeBSD4/pickleit pickled "pickle this" read back "pickle this" (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that pickled "pickle that" read back "pickle that" === On PPC_DARWIN with the latest CM3: [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickled "pickle this" read back "pickle this" [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that pickled "pickle that" *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** Abort === On FreeBSD4 with the latest CM3: (73)rover:~/ptest/src>../FreeBSD4/pickleit pickled "pickle this" read back "pickle this" (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that pickled "pickle that" *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** Abort ============ Diagnosis: The code I mentioned in a previous email declares a Text8CString.T to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere in the system, Ctypes.char_star is specifically declared to be an "UNTRACED REF Ctypes.char". According to the specification of Pickle, an UNTRACED REF is pickled as NIL. Generally speaking, you don't see many Text8CString.Ts in the system. This one comes in via Params.Get, which in turn calls RTArgs.GetArg, which in turn calls M3toC.StoT. StoT is generally not something you want to call, but it's supposed to be OK here because you're just passing around argv, which won't change. Generally speaking, it ought to be OK to use to convert C strings whose addresses aren't going to change during the lifetime of the program. I think it is *totally unacceptable* that Params.Get returns a "poisoned" TEXT. There is absolutely nothing in any of the interfaces that warns of this fact, and it is surprising to say the least. There is also no simple way of "copying" TEXTs, as it shouldn't ever be required! Finally, there's no way of checking whether a TEXT is a Text8CString.T without importing Text8CString, which is an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! What does baffle me a bit is that the code works on the old PM3. It uses the old TextF, which declares TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; The old (from PM3, I think it's 1.1.15) M3toC has: PROCEDURE StoT (s: Ctypes.char_star): TEXT = VAR t := NEW (M3TextWithHeader); BEGIN t.header.typecode := RT0.TextTypecode; t.body.chars := LOOPHOLE (s, ADDRESS); t.body.length := 1 + Cstring.strlen (s); RETURN LOOPHOLE (ADR (t.body), TEXT); END StoT; I'm not entirely sure why the old code works---why isn't the M3TextWithHeader garbage-collected? The pickler doesn't seem to know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. In fact the pickler doesn't seem to know anything about TEXTs at all. I see several possible ways of solving the problem. One is to permit M3toC.StoT to remain broken (since M3toC is an UNSAFE interface, there's no "legal" reason not to do that) and make sure Params.Get (and everything else that could remotely be called "standard") doesn't use M3toC.StoT---oh and to leave some very prominent warning signs, both in M3toC and Text8CString that "here be demons". Another is to revert to the SRC method of LOOPHOLEing the C strings. I never liked the CM3 TEXTs, and I like them even less now; I disliked them from the start because they broke pickle compatibility with SRC M3, and now I find that they aren't even compatible with themselves. Modula-3's strengths have always been its utter simplicity and bullet-proof reliability. This stuff, where some objects are more "serializable" than others, reminds me of Java! Does anyone have an opinion as to how this problem ought to be solved? Mika Mika Nystrom writes: >Hello everyone, > >Here's a random question that hopefully someone can answer... > >Is it true that certain TEXTs can't be Pickled under CM3? > >Unless there's some magic I don't understand going on, I am thinking >that would be the implication of: > >UNSAFE INTERFACE Text8CString; >... >TYPE > T <: Public; > Public = TEXT OBJECT > str: Ctypes.char_star; > END; > (* The array contains the characters of the text followed by a '\000'. *) >... > >I hope someone can set me straight and tell me that no, the situation >isn't as dire as that---some clever thing somewhere makes it possible >to Pickle all objects of type TEXT... > > Mika From hosking at cs.purdue.edu Thu Jul 26 15:47:46 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 09:47:46 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Message-ID: Looks like we need to fix M3toC.StoT so that it works the same as old PM3. The old code works because it constructs a text *in* the heap as an ARRAY OF CHAR, that just happens to have its payload (the array contents) outside the heap. (Arrays in M3 contain a reference to their data). We can play the same trick for Text8CString and get things to work properly for you. I will make this fix and check it in. On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: > Ok, I am about to answer my own email. Here's a little program I > wrote: > > MODULE Main; > IMPORT Pickle, IO, Params, TextWr, TextRd; > > VAR wr := NEW(TextWr.T).init(); > toPickle := "pickle this"; > BEGIN > IF Params.Count > 1 THEN toPickle := Params.Get(1) END; > > Pickle.Write(wr,toPickle); > > IO.Put("pickled \""&toPickle&"\"\n"); > IO.Put("read back \""& > Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) > &"\"\n"); > END Main. > > === On FreeBSD4 with my ancient, creaky PM3: > > (64)trs80:~/ptest/src>../FreeBSD4/pickleit > pickled "pickle this" > read back "pickle this" > (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that > pickled "pickle that" > read back "pickle that" > > === On PPC_DARWIN with the latest CM3: > > [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit > pickled "pickle this" > read back "pickle this" > [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that > pickled "pickle that" > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** > > Abort > > === On FreeBSD4 with the latest CM3: > > (73)rover:~/ptest/src>../FreeBSD4/pickleit > pickled "pickle this" > read back "pickle this" > (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that > pickled "pickle that" > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** > > Abort > > ============ > > Diagnosis: > > The code I mentioned in a previous email declares a Text8CString.T > to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere > in the system, Ctypes.char_star is specifically declared to be an > "UNTRACED REF Ctypes.char". According to the specification of > Pickle, an UNTRACED REF is pickled as NIL. > > Generally speaking, you don't see many Text8CString.Ts in the system. > This one comes in via Params.Get, which in turn calls RTArgs.GetArg, > which in turn calls M3toC.StoT. > > StoT is generally not something you want to call, but it's supposed > to be OK here because you're just passing around argv, which won't > change. Generally speaking, it ought to be OK to use to convert > C strings whose addresses aren't going to change during the lifetime > of the program. > > I think it is *totally unacceptable* that Params.Get returns a > "poisoned" TEXT. There is absolutely nothing in any of the interfaces > that warns of this fact, and it is surprising to say the least. > There is also no simple way of "copying" TEXTs, as it shouldn't > ever be required! Finally, there's no way of checking whether a > TEXT is a Text8CString.T without importing Text8CString, which is > an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! > > What does baffle me a bit is that the code works on the old PM3. > It uses the old TextF, which declares > > TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; > > The old (from PM3, I think it's 1.1.15) M3toC has: > > PROCEDURE StoT (s: Ctypes.char_star): TEXT = > VAR t := NEW (M3TextWithHeader); > BEGIN > t.header.typecode := RT0.TextTypecode; > t.body.chars := LOOPHOLE (s, ADDRESS); > t.body.length := 1 + Cstring.strlen (s); > RETURN LOOPHOLE (ADR (t.body), TEXT); > END StoT; > > I'm not entirely sure why the old code works---why isn't the > M3TextWithHeader garbage-collected? The pickler doesn't seem to > know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. > In fact the pickler doesn't seem to know anything about TEXTs > at all. > > I see several possible ways of solving the problem. One is to > permit M3toC.StoT to remain broken (since M3toC is an UNSAFE > interface, there's no "legal" reason not to do that) and make sure > Params.Get (and everything else that could remotely be called > "standard") doesn't use M3toC.StoT---oh and to leave some very > prominent warning signs, both in M3toC and Text8CString that "here > be demons". Another is to revert to the SRC method of LOOPHOLEing > the C strings. I never liked the CM3 TEXTs, and I like them even > less now; I disliked them from the start because they broke pickle > compatibility with SRC M3, and now I find that they aren't even > compatible with themselves. > > Modula-3's strengths have always been its utter simplicity > and bullet-proof reliability. This stuff, where some objects are > more "serializable" than others, reminds me of Java! > > Does anyone have an opinion as to how this problem ought to be > solved? > > Mika > > Mika Nystrom writes: >> Hello everyone, >> >> Here's a random question that hopefully someone can answer... >> >> Is it true that certain TEXTs can't be Pickled under CM3? >> >> Unless there's some magic I don't understand going on, I am thinking >> that would be the implication of: >> >> UNSAFE INTERFACE Text8CString; >> ... >> TYPE >> T <: Public; >> Public = TEXT OBJECT >> str: Ctypes.char_star; >> END; >> (* The array contains the characters of the text followed by a >> '\000'. *) >> ... >> >> I hope someone can set me straight and tell me that no, the situation >> isn't as dire as that---some clever thing somewhere makes it possible >> to Pickle all objects of type TEXT... >> >> Mika From mika at async.caltech.edu Thu Jul 26 16:04:07 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Jul 2007 07:04:07 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Thu, 26 Jul 2007 09:47:46 EDT." Message-ID: <200707261404.l6QE47LU009706@camembert.async.caltech.edu> Tony Hosking writes: >Looks like we need to fix M3toC.StoT so that it works the same as old >PM3. The old code works because it constructs a text *in* the heap >as an ARRAY OF CHAR, that just happens to have its payload (the array >contents) outside the heap. (Arrays in M3 contain a reference to >their data). We can play the same trick for Text8CString and get >things to work properly for you. I will make this fix and check it in. > > >On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: ... >> Does anyone have an opinion as to how this problem ought to be >> solved? >> ... that's more than an opinion, but I'll happily accept it! :-) Mika From hosking at cs.purdue.edu Thu Jul 26 17:26:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 11:26:31 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Message-ID: <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> On closer inspection, it is even messier than that. In the old PM3 the text that is constructed is allocated in UNTRACED storage (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be GC'd, and looks (to the GC) like an (old-style) text literal allocated outside the heap. It is harder for us to fake up a text literal like this with the new TEXT setup since we'd need to allocate, copy, and loophole something that looks like a text literal (an object) in the untraced heap. The best alternative is to fix the pickler with a special that handles Text8Cstrings. I think this is the cleanest approach. Mika, please try the following program, which adds a special for Text8CString. I will put this code into the builtin specials for pickles. On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: > Looks like we need to fix M3toC.StoT so that it works the same as > old PM3. The old code works because it constructs a text *in* the > heap as an ARRAY OF CHAR, that just happens to have its payload > (the array contents) outside the heap. (Arrays in M3 contain a > reference to their data). We can play the same trick for > Text8CString and get things to work properly for you. I will make > this fix and check it in. > > > On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: > >> Ok, I am about to answer my own email. Here's a little program I >> wrote: >> >> MODULE Main; >> IMPORT Pickle, IO, Params, TextWr, TextRd; >> >> VAR wr := NEW(TextWr.T).init(); >> toPickle := "pickle this"; >> BEGIN >> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >> >> Pickle.Write(wr,toPickle); >> >> IO.Put("pickled \""&toPickle&"\"\n"); >> IO.Put("read back \""& >> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >> &"\"\n"); >> END Main. >> >> === On FreeBSD4 with my ancient, creaky PM3: >> >> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >> pickled "pickle this" >> read back "pickle this" >> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >> pickled "pickle that" >> read back "pickle that" >> >> === On PPC_DARWIN with the latest CM3: >> >> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >> pickled "pickle this" >> read back "pickle this" >> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >> pickled "pickle that" >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** >> >> Abort >> >> === On FreeBSD4 with the latest CM3: >> >> (73)rover:~/ptest/src>../FreeBSD4/pickleit >> pickled "pickle this" >> read back "pickle this" >> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >> pickled "pickle that" >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** >> >> Abort >> >> ============ >> >> Diagnosis: >> >> The code I mentioned in a previous email declares a Text8CString.T >> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >> in the system, Ctypes.char_star is specifically declared to be an >> "UNTRACED REF Ctypes.char". According to the specification of >> Pickle, an UNTRACED REF is pickled as NIL. >> >> Generally speaking, you don't see many Text8CString.Ts in the system. >> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >> which in turn calls M3toC.StoT. >> >> StoT is generally not something you want to call, but it's supposed >> to be OK here because you're just passing around argv, which won't >> change. Generally speaking, it ought to be OK to use to convert >> C strings whose addresses aren't going to change during the lifetime >> of the program. >> >> I think it is *totally unacceptable* that Params.Get returns a >> "poisoned" TEXT. There is absolutely nothing in any of the >> interfaces >> that warns of this fact, and it is surprising to say the least. >> There is also no simple way of "copying" TEXTs, as it shouldn't >> ever be required! Finally, there's no way of checking whether a >> TEXT is a Text8CString.T without importing Text8CString, which is >> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >> >> What does baffle me a bit is that the code works on the old PM3. >> It uses the old TextF, which declares >> >> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >> >> The old (from PM3, I think it's 1.1.15) M3toC has: >> >> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >> VAR t := NEW (M3TextWithHeader); >> BEGIN >> t.header.typecode := RT0.TextTypecode; >> t.body.chars := LOOPHOLE (s, ADDRESS); >> t.body.length := 1 + Cstring.strlen (s); >> RETURN LOOPHOLE (ADR (t.body), TEXT); >> END StoT; >> >> I'm not entirely sure why the old code works---why isn't the >> M3TextWithHeader garbage-collected? The pickler doesn't seem to >> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >> In fact the pickler doesn't seem to know anything about TEXTs >> at all. >> >> I see several possible ways of solving the problem. One is to >> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >> interface, there's no "legal" reason not to do that) and make sure >> Params.Get (and everything else that could remotely be called >> "standard") doesn't use M3toC.StoT---oh and to leave some very >> prominent warning signs, both in M3toC and Text8CString that "here >> be demons". Another is to revert to the SRC method of LOOPHOLEing >> the C strings. I never liked the CM3 TEXTs, and I like them even >> less now; I disliked them from the start because they broke pickle >> compatibility with SRC M3, and now I find that they aren't even >> compatible with themselves. >> >> Modula-3's strengths have always been its utter simplicity >> and bullet-proof reliability. This stuff, where some objects are >> more "serializable" than others, reminds me of Java! >> >> Does anyone have an opinion as to how this problem ought to be >> solved? >> >> Mika >> >> Mika Nystrom writes: >>> Hello everyone, >>> >>> Here's a random question that hopefully someone can answer... >>> >>> Is it true that certain TEXTs can't be Pickled under CM3? >>> >>> Unless there's some magic I don't understand going on, I am thinking >>> that would be the implication of: >>> >>> UNSAFE INTERFACE Text8CString; >>> ... >>> TYPE >>> T <: Public; >>> Public = TEXT OBJECT >>> str: Ctypes.char_star; >>> END; >>> (* The array contains the characters of the text followed by a >>> '\000'. *) >>> ... >>> >>> I hope someone can set me straight and tell me that no, the >>> situation >>> isn't as dire as that---some clever thing somewhere makes it >>> possible >>> to Pickle all objects of type TEXT... >>> >>> Mika From hosking at cs.purdue.edu Thu Jul 26 18:02:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 12:02:19 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> Message-ID: I'm about to check in the fix. I have tested this with your example program and things work fine. On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: > On closer inspection, it is even messier than that. In the old PM3 > the text that is constructed is allocated in UNTRACED storage > (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be > GC'd, and looks (to the GC) like an (old-style) text literal > allocated outside the heap. It is harder for us to fake up a text > literal like this with the new TEXT setup since we'd need to > allocate, copy, and loophole something that looks like a text > literal (an object) in the untraced heap. The best alternative is > to fix the pickler with a special that handles Text8Cstrings. I > think this is the cleanest approach. Mika, please try the > following program, which adds a special for Text8CString. I will > put this code into the builtin specials for pickles. > > On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: > >> Looks like we need to fix M3toC.StoT so that it works the same as >> old PM3. The old code works because it constructs a text *in* the >> heap as an ARRAY OF CHAR, that just happens to have its payload >> (the array contents) outside the heap. (Arrays in M3 contain a >> reference to their data). We can play the same trick for >> Text8CString and get things to work properly for you. I will make >> this fix and check it in. >> >> >> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >> >>> Ok, I am about to answer my own email. Here's a little program I >>> wrote: >>> >>> MODULE Main; >>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>> >>> VAR wr := NEW(TextWr.T).init(); >>> toPickle := "pickle this"; >>> BEGIN >>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>> >>> Pickle.Write(wr,toPickle); >>> >>> IO.Put("pickled \""&toPickle&"\"\n"); >>> IO.Put("read back \""& >>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>> &"\"\n"); >>> END Main. >>> >>> === On FreeBSD4 with my ancient, creaky PM3: >>> >>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>> pickled "pickle that" >>> read back "pickle that" >>> >>> === On PPC_DARWIN with the latest CM3: >>> >>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>> pickled "pickle that" >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** >>> >>> Abort >>> >>> === On FreeBSD4 with the latest CM3: >>> >>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>> pickled "pickle that" >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** >>> >>> Abort >>> >>> ============ >>> >>> Diagnosis: >>> >>> The code I mentioned in a previous email declares a Text8CString.T >>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>> in the system, Ctypes.char_star is specifically declared to be an >>> "UNTRACED REF Ctypes.char". According to the specification of >>> Pickle, an UNTRACED REF is pickled as NIL. >>> >>> Generally speaking, you don't see many Text8CString.Ts in the >>> system. >>> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >>> which in turn calls M3toC.StoT. >>> >>> StoT is generally not something you want to call, but it's supposed >>> to be OK here because you're just passing around argv, which won't >>> change. Generally speaking, it ought to be OK to use to convert >>> C strings whose addresses aren't going to change during the lifetime >>> of the program. >>> >>> I think it is *totally unacceptable* that Params.Get returns a >>> "poisoned" TEXT. There is absolutely nothing in any of the >>> interfaces >>> that warns of this fact, and it is surprising to say the least. >>> There is also no simple way of "copying" TEXTs, as it shouldn't >>> ever be required! Finally, there's no way of checking whether a >>> TEXT is a Text8CString.T without importing Text8CString, which is >>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>> >>> What does baffle me a bit is that the code works on the old PM3. >>> It uses the old TextF, which declares >>> >>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>> >>> The old (from PM3, I think it's 1.1.15) M3toC has: >>> >>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>> VAR t := NEW (M3TextWithHeader); >>> BEGIN >>> t.header.typecode := RT0.TextTypecode; >>> t.body.chars := LOOPHOLE (s, ADDRESS); >>> t.body.length := 1 + Cstring.strlen (s); >>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>> END StoT; >>> >>> I'm not entirely sure why the old code works---why isn't the >>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>> In fact the pickler doesn't seem to know anything about TEXTs >>> at all. >>> >>> I see several possible ways of solving the problem. One is to >>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>> interface, there's no "legal" reason not to do that) and make sure >>> Params.Get (and everything else that could remotely be called >>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>> prominent warning signs, both in M3toC and Text8CString that "here >>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>> the C strings. I never liked the CM3 TEXTs, and I like them even >>> less now; I disliked them from the start because they broke pickle >>> compatibility with SRC M3, and now I find that they aren't even >>> compatible with themselves. >>> >>> Modula-3's strengths have always been its utter simplicity >>> and bullet-proof reliability. This stuff, where some objects are >>> more "serializable" than others, reminds me of Java! >>> >>> Does anyone have an opinion as to how this problem ought to be >>> solved? >>> >>> Mika >>> >>> Mika Nystrom writes: >>>> Hello everyone, >>>> >>>> Here's a random question that hopefully someone can answer... >>>> >>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>> >>>> Unless there's some magic I don't understand going on, I am >>>> thinking >>>> that would be the implication of: >>>> >>>> UNSAFE INTERFACE Text8CString; >>>> ... >>>> TYPE >>>> T <: Public; >>>> Public = TEXT OBJECT >>>> str: Ctypes.char_star; >>>> END; >>>> (* The array contains the characters of the text followed by a >>>> '\000'. *) >>>> ... >>>> >>>> I hope someone can set me straight and tell me that no, the >>>> situation >>>> isn't as dire as that---some clever thing somewhere makes it >>>> possible >>>> to Pickle all objects of type TEXT... >>>> >>>> Mika From mika at async.caltech.edu Fri Jul 27 17:04:14 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Jul 2007 08:04:14 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Thu, 26 Jul 2007 12:02:19 EDT." Message-ID: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> Hi Tony, Sorry it took me a day to check up on this. I lost access to my 10.4 system and got my 10.3 back from Apple. You are right, your fix solved the pickle problem. Thank you very much, as always! Yes I realized it was doing something very tricky when I looked at the code... I also tested all my various software, and some of the CM3 programs, on 10.3. I can report the following: 1. The crash in Juno's virtual machine is gone 2. The threads taking 100% no longer do (I think this was the same bug that caused.. deadlock was it?.. on 10.4) 3. And of course the pickling is working great. But... 4. Bresenham still locks up for me. It does this, more often than not, on both 10.3 and 10.4. I'm really surprised it never does it for you! (Although it is true it sometimes work.) 5. I am still using @M3noincremental to run ktok, but it's the *only* program that seems to require it. Almost everything looks really good! Mika Tony Hosking writes: >I'm about to check in the fix. I have tested this with your example >program and things work fine. > >On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: > >> On closer inspection, it is even messier than that. In the old PM3 >> the text that is constructed is allocated in UNTRACED storage >> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >> GC'd, and looks (to the GC) like an (old-style) text literal >> allocated outside the heap. It is harder for us to fake up a text >> literal like this with the new TEXT setup since we'd need to >> allocate, copy, and loophole something that looks like a text >> literal (an object) in the untraced heap. The best alternative is >> to fix the pickler with a special that handles Text8Cstrings. I >> think this is the cleanest approach. Mika, please try the >> following program, which adds a special for Text8CString. I will >> put this code into the builtin specials for pickles. >> >> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >> >>> Looks like we need to fix M3toC.StoT so that it works the same as >>> old PM3. The old code works because it constructs a text *in* the >>> heap as an ARRAY OF CHAR, that just happens to have its payload >>> (the array contents) outside the heap. (Arrays in M3 contain a >>> reference to their data). We can play the same trick for >>> Text8CString and get things to work properly for you. I will make >>> this fix and check it in. >>> >>> >>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>> >>>> Ok, I am about to answer my own email. Here's a little program I >>>> wrote: >>>> >>>> MODULE Main; >>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>> >>>> VAR wr := NEW(TextWr.T).init(); >>>> toPickle := "pickle this"; >>>> BEGIN >>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>> >>>> Pickle.Write(wr,toPickle); >>>> >>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>> IO.Put("read back \""& >>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>> &"\"\n"); >>>> END Main. >>>> >>>> === On FreeBSD4 with my ancient, creaky PM3: >>>> >>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>> pickled "pickle that" >>>> read back "pickle that" >>>> >>>> === On PPC_DARWIN with the latest CM3: >>>> >>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>> pickled "pickle that" >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** >>>> >>>> Abort >>>> >>>> === On FreeBSD4 with the latest CM3: >>>> >>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>> pickled "pickle that" >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** >>>> >>>> Abort >>>> >>>> ============ >>>> >>>> Diagnosis: >>>> >>>> The code I mentioned in a previous email declares a Text8CString.T >>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>> in the system, Ctypes.char_star is specifically declared to be an >>>> "UNTRACED REF Ctypes.char". According to the specification of >>>> Pickle, an UNTRACED REF is pickled as NIL. >>>> >>>> Generally speaking, you don't see many Text8CString.Ts in the >>>> system. >>>> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >>>> which in turn calls M3toC.StoT. >>>> >>>> StoT is generally not something you want to call, but it's supposed >>>> to be OK here because you're just passing around argv, which won't >>>> change. Generally speaking, it ought to be OK to use to convert >>>> C strings whose addresses aren't going to change during the lifetime >>>> of the program. >>>> >>>> I think it is *totally unacceptable* that Params.Get returns a >>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>> interfaces >>>> that warns of this fact, and it is surprising to say the least. >>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>> ever be required! Finally, there's no way of checking whether a >>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>>> >>>> What does baffle me a bit is that the code works on the old PM3. >>>> It uses the old TextF, which declares >>>> >>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>> >>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>> >>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>> VAR t := NEW (M3TextWithHeader); >>>> BEGIN >>>> t.header.typecode := RT0.TextTypecode; >>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>> t.body.length := 1 + Cstring.strlen (s); >>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>> END StoT; >>>> >>>> I'm not entirely sure why the old code works---why isn't the >>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>> In fact the pickler doesn't seem to know anything about TEXTs >>>> at all. >>>> >>>> I see several possible ways of solving the problem. One is to >>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>> interface, there's no "legal" reason not to do that) and make sure >>>> Params.Get (and everything else that could remotely be called >>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>> prominent warning signs, both in M3toC and Text8CString that "here >>>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>> less now; I disliked them from the start because they broke pickle >>>> compatibility with SRC M3, and now I find that they aren't even >>>> compatible with themselves. >>>> >>>> Modula-3's strengths have always been its utter simplicity >>>> and bullet-proof reliability. This stuff, where some objects are >>>> more "serializable" than others, reminds me of Java! >>>> >>>> Does anyone have an opinion as to how this problem ought to be >>>> solved? >>>> >>>> Mika >>>> >>>> Mika Nystrom writes: >>>>> Hello everyone, >>>>> >>>>> Here's a random question that hopefully someone can answer... >>>>> >>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>> >>>>> Unless there's some magic I don't understand going on, I am >>>>> thinking >>>>> that would be the implication of: >>>>> >>>>> UNSAFE INTERFACE Text8CString; >>>>> ... >>>>> TYPE >>>>> T <: Public; >>>>> Public = TEXT OBJECT >>>>> str: Ctypes.char_star; >>>>> END; >>>>> (* The array contains the characters of the text followed by a >>>>> '\000'. *) >>>>> ... >>>>> >>>>> I hope someone can set me straight and tell me that no, the >>>>> situation >>>>> isn't as dire as that---some clever thing somewhere makes it >>>>> possible >>>>> to Pickle all objects of type TEXT... >>>>> >>>>> Mika From hosking at cs.purdue.edu Fri Jul 27 18:40:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Jul 2007 12:40:44 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> References: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> Message-ID: <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> On Jul 27, 2007, at 11:04 AM, Mika Nystrom wrote: > Hi Tony, > > Sorry it took me a day to check up on this. I lost access to my > 10.4 system and got my 10.3 back from Apple. > > You are right, your fix solved the pickle problem. Thank you very > much, > as always! Yes I realized it was doing something very tricky when I > looked at the code... > > I also tested all my various software, and some of the CM3 > programs, on > 10.3. I can report the following: > > 1. The crash in Juno's virtual machine is gone > 2. The threads taking 100% no longer do (I think this was the same > bug that > caused.. deadlock was it?.. on 10.4) > 3. And of course the pickling is working great. Great! > But... > > 4. Bresenham still locks up for me. It does this, more often than > not, > on both 10.3 and 10.4. I'm really surprised it never does it for you! > (Although it is true it sometimes work.) Yes, this problem seems to manifest only on Darwin, and I am seeing the issue with Bresenham as you do. I think it is a VBT issue that I have isolated to the following small program, which works fine for me on Linux, but which has always caused problems on Darwin locking up and not responding (I strongly suspect the Darwin X implementation rather than the threads system, but need still to diagnose the issue): MODULE Main; IMPORT ButtonVBT, HighlightVBT, VBT, TextVBT, Filter, Text, Trestle, BorderedVBT, Compiler, RTIO; PROCEDURE Flip(b: ButtonVBT.T; <*UNUSED*> READONLY cd: VBT.MouseRec) RAISES {}= BEGIN WITH ch = Filter.Child(b), txt = TextVBT.Get(ch) DO IF Text.Equal(txt, "Alpha") THEN TextVBT.Put(ch, "Beta") ELSE TextVBT.Put(ch, "Alpha") END END END Flip; VAR button := ButtonVBT.New(TextVBT.New("Alpha"), Flip); root := BorderedVBT.New(button); BEGIN RTIO.PutText(Compiler.ThisFile()); RTIO.PutChar('\n'); RTIO.PutText(Compiler.ThisPath()); RTIO.PutChar('\n'); RTIO.PutInt(Compiler.ThisLine()); RTIO.PutChar('\n'); RTIO.Flush(); Trestle.Install(root); Trestle.AwaitDelete(root); END Main. > 5. I am still using @M3noincremental to run ktok, but it's the *only* > program that seems to require it. I would like to figure this one out soon, as it really is a worry to me -- I am concerned that the new incremental GC support be as robust as possible and this is the only outstanding issue with it of which I am aware. > > Almost everything looks really good! > > Mika > > Tony Hosking writes: >> I'm about to check in the fix. I have tested this with your example >> program and things work fine. >> >> On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: >> >>> On closer inspection, it is even messier than that. In the old PM3 >>> the text that is constructed is allocated in UNTRACED storage >>> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >>> GC'd, and looks (to the GC) like an (old-style) text literal >>> allocated outside the heap. It is harder for us to fake up a text >>> literal like this with the new TEXT setup since we'd need to >>> allocate, copy, and loophole something that looks like a text >>> literal (an object) in the untraced heap. The best alternative is >>> to fix the pickler with a special that handles Text8Cstrings. I >>> think this is the cleanest approach. Mika, please try the >>> following program, which adds a special for Text8CString. I will >>> put this code into the builtin specials for pickles. >>> >>> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >>> >>>> Looks like we need to fix M3toC.StoT so that it works the same as >>>> old PM3. The old code works because it constructs a text *in* the >>>> heap as an ARRAY OF CHAR, that just happens to have its payload >>>> (the array contents) outside the heap. (Arrays in M3 contain a >>>> reference to their data). We can play the same trick for >>>> Text8CString and get things to work properly for you. I will make >>>> this fix and check it in. >>>> >>>> >>>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>>> >>>>> Ok, I am about to answer my own email. Here's a little program I >>>>> wrote: >>>>> >>>>> MODULE Main; >>>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>>> >>>>> VAR wr := NEW(TextWr.T).init(); >>>>> toPickle := "pickle this"; >>>>> BEGIN >>>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>>> >>>>> Pickle.Write(wr,toPickle); >>>>> >>>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>>> IO.Put("read back \""& >>>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>>> &"\"\n"); >>>>> END Main. >>>>> >>>>> === On FreeBSD4 with my ancient, creaky PM3: >>>>> >>>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> read back "pickle that" >>>>> >>>>> === On PPC_DARWIN with the latest CM3: >>>>> >>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference >>>>> NIL >>>>> *** >>>>> >>>>> Abort >>>>> >>>>> === On FreeBSD4 with the latest CM3: >>>>> >>>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference >>>>> NIL >>>>> *** >>>>> >>>>> Abort >>>>> >>>>> ============ >>>>> >>>>> Diagnosis: >>>>> >>>>> The code I mentioned in a previous email declares a Text8CString.T >>>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>>> in the system, Ctypes.char_star is specifically declared to be an >>>>> "UNTRACED REF Ctypes.char". According to the specification of >>>>> Pickle, an UNTRACED REF is pickled as NIL. >>>>> >>>>> Generally speaking, you don't see many Text8CString.Ts in the >>>>> system. >>>>> This one comes in via Params.Get, which in turn calls >>>>> RTArgs.GetArg, >>>>> which in turn calls M3toC.StoT. >>>>> >>>>> StoT is generally not something you want to call, but it's >>>>> supposed >>>>> to be OK here because you're just passing around argv, which won't >>>>> change. Generally speaking, it ought to be OK to use to convert >>>>> C strings whose addresses aren't going to change during the >>>>> lifetime >>>>> of the program. >>>>> >>>>> I think it is *totally unacceptable* that Params.Get returns a >>>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>>> interfaces >>>>> that warns of this fact, and it is surprising to say the least. >>>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>>> ever be required! Finally, there's no way of checking whether a >>>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>>>> >>>>> What does baffle me a bit is that the code works on the old PM3. >>>>> It uses the old TextF, which declares >>>>> >>>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>>> >>>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>>> >>>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>>> VAR t := NEW (M3TextWithHeader); >>>>> BEGIN >>>>> t.header.typecode := RT0.TextTypecode; >>>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>>> t.body.length := 1 + Cstring.strlen (s); >>>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>>> END StoT; >>>>> >>>>> I'm not entirely sure why the old code works---why isn't the >>>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>>> In fact the pickler doesn't seem to know anything about TEXTs >>>>> at all. >>>>> >>>>> I see several possible ways of solving the problem. One is to >>>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>>> interface, there's no "legal" reason not to do that) and make sure >>>>> Params.Get (and everything else that could remotely be called >>>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>>> prominent warning signs, both in M3toC and Text8CString that "here >>>>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>>> less now; I disliked them from the start because they broke pickle >>>>> compatibility with SRC M3, and now I find that they aren't even >>>>> compatible with themselves. >>>>> >>>>> Modula-3's strengths have always been its utter simplicity >>>>> and bullet-proof reliability. This stuff, where some objects are >>>>> more "serializable" than others, reminds me of Java! >>>>> >>>>> Does anyone have an opinion as to how this problem ought to be >>>>> solved? >>>>> >>>>> Mika >>>>> >>>>> Mika Nystrom writes: >>>>>> Hello everyone, >>>>>> >>>>>> Here's a random question that hopefully someone can answer... >>>>>> >>>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>>> >>>>>> Unless there's some magic I don't understand going on, I am >>>>>> thinking >>>>>> that would be the implication of: >>>>>> >>>>>> UNSAFE INTERFACE Text8CString; >>>>>> ... >>>>>> TYPE >>>>>> T <: Public; >>>>>> Public = TEXT OBJECT >>>>>> str: Ctypes.char_star; >>>>>> END; >>>>>> (* The array contains the characters of the text followed by a >>>>>> '\000'. *) >>>>>> ... >>>>>> >>>>>> I hope someone can set me straight and tell me that no, the >>>>>> situation >>>>>> isn't as dire as that---some clever thing somewhere makes it >>>>>> possible >>>>>> to Pickle all objects of type TEXT... >>>>>> >>>>>> Mika From hosking at cs.purdue.edu Fri Jul 27 19:23:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Jul 2007 13:23:43 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> References: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> Message-ID: <7120B06C-A59A-4509-A857-E5B9A72206E6@cs.purdue.edu> On Jul 27, 2007, at 12:40 PM, Tony Hosking wrote: > > On Jul 27, 2007, at 11:04 AM, Mika Nystrom wrote: > >> Hi Tony, >> >> Sorry it took me a day to check up on this. I lost access to my >> 10.4 system and got my 10.3 back from Apple. >> >> You are right, your fix solved the pickle problem. Thank you very >> much, >> as always! Yes I realized it was doing something very tricky when I >> looked at the code... >> >> I also tested all my various software, and some of the CM3 >> programs, on >> 10.3. I can report the following: >> >> 1. The crash in Juno's virtual machine is gone >> 2. The threads taking 100% no longer do (I think this was the same >> bug that >> caused.. deadlock was it?.. on 10.4) >> 3. And of course the pickling is working great. > > Great! > >> But... >> >> 4. Bresenham still locks up for me. It does this, more often than >> not, >> on both 10.3 and 10.4. I'm really surprised it never does it for >> you! >> (Although it is true it sometimes work.) > > Yes, this problem seems to manifest only on Darwin, and I am seeing > the issue with Bresenham as you do. I think it is a VBT issue that > I have isolated to the following small program, which works fine > for me on Linux, but which has always caused problems on Darwin > locking up and not responding (I strongly suspect the Darwin X > implementation rather than the threads system, but need still to > diagnose the issue): > > MODULE Main; > > IMPORT ButtonVBT, HighlightVBT, VBT, TextVBT, Filter, Text, > Trestle, BorderedVBT, > Compiler, RTIO; > > PROCEDURE Flip(b: ButtonVBT.T; <*UNUSED*> READONLY cd: > VBT.MouseRec) RAISES {}= > BEGIN > WITH ch = Filter.Child(b), txt = TextVBT.Get(ch) DO > IF Text.Equal(txt, "Alpha") THEN > TextVBT.Put(ch, "Beta") > ELSE > TextVBT.Put(ch, "Alpha") > END > END > END Flip; > > VAR > button := ButtonVBT.New(TextVBT.New("Alpha"), Flip); > root := BorderedVBT.New(button); > > BEGIN > RTIO.PutText(Compiler.ThisFile()); RTIO.PutChar('\n'); > RTIO.PutText(Compiler.ThisPath()); RTIO.PutChar('\n'); > RTIO.PutInt(Compiler.ThisLine()); RTIO.PutChar('\n'); > RTIO.Flush(); > Trestle.Install(root); > Trestle.AwaitDelete(root); > END Main. The fix for this program is to set Xquartz defaults as follows (see the manual to see how to do this): defaults write com.apple.x11 wm_click_through -bool true I have still not diagnosed the issue with mentor running Bresenham. > > >> 5. I am still using @M3noincremental to run ktok, but it's the *only* >> program that seems to require it. > > I would like to figure this one out soon, as it really is a worry > to me -- I am concerned that the new incremental GC support be as > robust as possible and this is the only outstanding issue with it > of which I am aware. > >> >> Almost everything looks really good! >> >> Mika >> >> Tony Hosking writes: >>> I'm about to check in the fix. I have tested this with your example >>> program and things work fine. >>> >>> On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: >>> >>>> On closer inspection, it is even messier than that. In the old PM3 >>>> the text that is constructed is allocated in UNTRACED storage >>>> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >>>> GC'd, and looks (to the GC) like an (old-style) text literal >>>> allocated outside the heap. It is harder for us to fake up a text >>>> literal like this with the new TEXT setup since we'd need to >>>> allocate, copy, and loophole something that looks like a text >>>> literal (an object) in the untraced heap. The best alternative is >>>> to fix the pickler with a special that handles Text8Cstrings. I >>>> think this is the cleanest approach. Mika, please try the >>>> following program, which adds a special for Text8CString. I will >>>> put this code into the builtin specials for pickles. >>>> >>>> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >>>> >>>>> Looks like we need to fix M3toC.StoT so that it works the same as >>>>> old PM3. The old code works because it constructs a text *in* the >>>>> heap as an ARRAY OF CHAR, that just happens to have its payload >>>>> (the array contents) outside the heap. (Arrays in M3 contain a >>>>> reference to their data). We can play the same trick for >>>>> Text8CString and get things to work properly for you. I will make >>>>> this fix and check it in. >>>>> >>>>> >>>>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>>>> >>>>>> Ok, I am about to answer my own email. Here's a little program I >>>>>> wrote: >>>>>> >>>>>> MODULE Main; >>>>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>>>> >>>>>> VAR wr := NEW(TextWr.T).init(); >>>>>> toPickle := "pickle this"; >>>>>> BEGIN >>>>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>>>> >>>>>> Pickle.Write(wr,toPickle); >>>>>> >>>>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>>>> IO.Put("read back \""& >>>>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>>>> &"\"\n"); >>>>>> END Main. >>>>>> >>>>>> === On FreeBSD4 with my ancient, creaky PM3: >>>>>> >>>>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> read back "pickle that" >>>>>> >>>>>> === On PPC_DARWIN with the latest CM3: >>>>>> >>>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to >>>>>> dereference NIL >>>>>> *** >>>>>> >>>>>> Abort >>>>>> >>>>>> === On FreeBSD4 with the latest CM3: >>>>>> >>>>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to >>>>>> dereference NIL >>>>>> *** >>>>>> >>>>>> Abort >>>>>> >>>>>> ============ >>>>>> >>>>>> Diagnosis: >>>>>> >>>>>> The code I mentioned in a previous email declares a >>>>>> Text8CString.T >>>>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>>>> in the system, Ctypes.char_star is specifically declared to be an >>>>>> "UNTRACED REF Ctypes.char". According to the specification of >>>>>> Pickle, an UNTRACED REF is pickled as NIL. >>>>>> >>>>>> Generally speaking, you don't see many Text8CString.Ts in the >>>>>> system. >>>>>> This one comes in via Params.Get, which in turn calls >>>>>> RTArgs.GetArg, >>>>>> which in turn calls M3toC.StoT. >>>>>> >>>>>> StoT is generally not something you want to call, but it's >>>>>> supposed >>>>>> to be OK here because you're just passing around argv, which >>>>>> won't >>>>>> change. Generally speaking, it ought to be OK to use to convert >>>>>> C strings whose addresses aren't going to change during the >>>>>> lifetime >>>>>> of the program. >>>>>> >>>>>> I think it is *totally unacceptable* that Params.Get returns a >>>>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>>>> interfaces >>>>>> that warns of this fact, and it is surprising to say the least. >>>>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>>>> ever be required! Finally, there's no way of checking whether a >>>>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>>>> an UNSAFE INTERFACE, which of course is illegal in a safe >>>>>> MODULE!! >>>>>> >>>>>> What does baffle me a bit is that the code works on the old PM3. >>>>>> It uses the old TextF, which declares >>>>>> >>>>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>>>> >>>>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>>>> >>>>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>>>> VAR t := NEW (M3TextWithHeader); >>>>>> BEGIN >>>>>> t.header.typecode := RT0.TextTypecode; >>>>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>>>> t.body.length := 1 + Cstring.strlen (s); >>>>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>>>> END StoT; >>>>>> >>>>>> I'm not entirely sure why the old code works---why isn't the >>>>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>>>> In fact the pickler doesn't seem to know anything about TEXTs >>>>>> at all. >>>>>> >>>>>> I see several possible ways of solving the problem. One is to >>>>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>>>> interface, there's no "legal" reason not to do that) and make >>>>>> sure >>>>>> Params.Get (and everything else that could remotely be called >>>>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>>>> prominent warning signs, both in M3toC and Text8CString that >>>>>> "here >>>>>> be demons". Another is to revert to the SRC method of >>>>>> LOOPHOLEing >>>>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>>>> less now; I disliked them from the start because they broke >>>>>> pickle >>>>>> compatibility with SRC M3, and now I find that they aren't even >>>>>> compatible with themselves. >>>>>> >>>>>> Modula-3's strengths have always been its utter simplicity >>>>>> and bullet-proof reliability. This stuff, where some objects are >>>>>> more "serializable" than others, reminds me of Java! >>>>>> >>>>>> Does anyone have an opinion as to how this problem ought to be >>>>>> solved? >>>>>> >>>>>> Mika >>>>>> >>>>>> Mika Nystrom writes: >>>>>>> Hello everyone, >>>>>>> >>>>>>> Here's a random question that hopefully someone can answer... >>>>>>> >>>>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>>>> >>>>>>> Unless there's some magic I don't understand going on, I am >>>>>>> thinking >>>>>>> that would be the implication of: >>>>>>> >>>>>>> UNSAFE INTERFACE Text8CString; >>>>>>> ... >>>>>>> TYPE >>>>>>> T <: Public; >>>>>>> Public = TEXT OBJECT >>>>>>> str: Ctypes.char_star; >>>>>>> END; >>>>>>> (* The array contains the characters of the text followed by a >>>>>>> '\000'. *) >>>>>>> ... >>>>>>> >>>>>>> I hope someone can set me straight and tell me that no, the >>>>>>> situation >>>>>>> isn't as dire as that---some clever thing somewhere makes it >>>>>>> possible >>>>>>> to Pickle all objects of type TEXT... >>>>>>> >>>>>>> Mika From elmstb at aon.at Wed Jul 4 20:33:14 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 18:33:14 -0000 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468BE796.8020802@aon.at> It seems to be the same message, which I have sent to you. Has there been anything new you wanted to tell me? Is the setjmp/longjmp replacement of interest? Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > However this may be less favourable than using makecontext since the > assembler routines will only work on i386 hardware. > Moreover setjmp/longjmp are said that they may cause the loss of > assignents, because they do not save certain registers(cx,dx) -> see > "Exception semantics" at > http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. > Nevertheless possible future changes on make/get/setcontext will not be > able to affect Modula-3 when extracting the SP from the context record > any more if it does not rely on glibc functions. > Another solution is to link against the old glibc files (unpacked into > /lib/anc): > > >> ldd $(which m3build) >> > linux-gate.so.1 => (0xffffe000) > libm3front.so.1 => > /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) > libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) > libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) > /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) > > Please tell me if you are intereseted in any of both solutions. > I would suppose a solution for CM3 not to differ that much. > > Yours, > Elmar Stellnberger > > > > Tony Hosking wrote: > >> I have a question that may influence the direction we take with >> user-level threading support. Currently, user-level threading is >> broken on platforms that implement secure setjmp/longjmp via >> encryption since hacking the jump buffers the way we currently do for >> user-level threading triggers longjmp errors. A better alternative is >> to use makecontext/getcontext/setcontext on platforms that support it. >> For example, I know of the following situation for the targets I track: >> >> Target System (pthreads) threads User (setjmp/longjmp) threads User >> (getcontext/setcontext) threads >> >> LINUXLIBC6 YES NO unimplemented >> SOLgnu YES unimplemented YES (but not using makecontext) >> PPC_DARWIN YES NO no getcontext/setcontext >> I386_DARWIN YES NO no getcontext/setcontext >> FreeBSD NO YES unimplemented >> >> Ideally, we would implement all user-level threading using makecontext >> and friends, but my question is how many of our user-level threading >> targets actually support that API? One strategy would be to >> re-implement user-level threading using makecontext, etc., but fake up >> makecontext support, etc., on those targets that don't have it. >> >> I would hate to lose the user-level thread support just because it >> makes sense in some situations (e.g., embedded, uni-processor). >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Fri Jul 13 18:17:34 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 13 Jul 2007 16:17:34 -0000 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <20070713161515.GC98227@ted.stsp.lan> On Fri, Jul 13, 2007 at 10:43:01AM -0500, Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts to > use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. No. It's a known issue. > Any pointers to documentation on what CVS really wants here? http://ximbiot.com/cvs/manual/cvs-1.12.6/cvs_18.html#SEC168 -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rcoleburn at scires.com Thu Jul 19 20:56:22 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 19 Jul 2007 18:56:22 -0000 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F7BAD.1E75.00D7.1@scires.com> Tony: I'd like to better understand the implications of your change as I do use LONGINT as an index in some applications. 1. On a computer with a 32-bit word size, will LONGINT be 32 bits or 64 bits? 2. I assume on a computer with a 64-bit word size, LONGINT will be 64 bits. Is there an option to get a 32-bit integer on these machines? 3. Would it make sense to keep LONGINT at 32-bits and make a new type, say LONGINT64, at 64-bits? Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> Tony Hosking 7/18/2007 11:53 PM >>> I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 20 22:48:34 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 20:48:34 -0000 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FDFDE.9020201@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FDFDE.9020201@wichita.edu> Message-ID: <05CD4EBC-E1C6-4BB7-919C-8032B5265609@cs.purdue.edu> I think I am coming around to Rodney's position. We should consider INTEGER and LONGINT assignable under the current rules for subranges. Thus, INTEGER := LONGINT will cause a range check (and underlying conversion of the integer value from BITSIZE(LONGINT) to BITSIZE(INTEGER)), whereas LONGINT := INTEGER will need not check (though the conversion will be necessary to extend sign as expected). I believe this functionality can easily be implemented in the current compiler. Also, I am willing to allow indexing of arrays using LONGINT-based ordinals for the index type. The usual restrictions on array size will obtain, and zero-based array indexes will be computed into integer offsets. Thus, for an array indexed [minL..maxL] where minL and maxL have base type LONGINT, the offset will be computed as: index - minL and converted to an INTEGER value to index the array. Because of the sizing restriction, index - minL must be expressible as an INTEGER. Here are my revised notes: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longint.txt URL: -------------- next part -------------- On Jul 19, 2007, at 6:04 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> On Jul 19, 2007, at 4:33 PM, Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >> There is no implicit conversion for floats. The danger with >> implicit conversion for integers is that it would not be >> portable: you would get different behavior on different machines >> for the same code. Better to make the conversion explicit so >> that programmers are prepared for the range check to fail. > > But is this argument any stronger for requiring explicit conversions > for INTEGER/LONGINT assignments than for assigning to subranges? > Many assignments in the language now, without any type conversion, > admit the possibility of RT range errors. And these can be dependent > on the size of INTEGER too. Consider: > > VAR V : [ 0 .. 65535 ] ; > VAR I : CARDINAL ; > ... > V := I DIV 2 ; > > I think for portability, the principle that the static semantics > should be > the same for all sizes of INTEGER (and LONGINT too) is as much as > we can > hope for. Certainly, there are already countless ways the integer > size can > change the dynamic semantics of a program. > > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From mika at async.caltech.edu Mon Jul 2 12:35:48 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 02 Jul 2007 03:35:48 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Thu, 28 Jun 2007 10:53:25 EDT." Message-ID: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:03:42 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:03:42 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:05:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:05:36 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: <3B964979-AD2A-41FD-8522-3B1D00D9CE9A@cs.purdue.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 2 17:49:57 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 11:49:57 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: <39E88F42-57CE-4AE0-8ED8-AF955B6A0E26@cs.purdue.edu> In follow up to my previous message, I think I may have a simpler fix. Can you please try the latest version of ThreadPosix.m3 that I just checked in. Unfortunately, I don't have a user-level threads system on which to try (Linux is broken because setjmp/longjmp use encryption to prevent stack-smashing security exploits), and my Solaris boxes are not available right now. 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 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? From dabenavidesd at yahoo.es Mon Jul 2 18:05:22 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 2 Jul 2007 18:05:22 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: Message-ID: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> Hi: In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the same problem is happensg, with the message of the RTCollector danielb at danielb-desktop:~$ mentor *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/runtime/common/RTCollector.m3", line 2310 *** Aborted danielb at danielb-desktop:~$ With the @M3noincremental runs fine, @M3nogc also doesnt break. --- Tony Hosking wrote: > 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, === message truncated === ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From hosking at cs.purdue.edu Mon Jul 2 21:50:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 15:50:44 -0400 Subject: [M3devel] strange errors... In-Reply-To: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> References: <20070702160522.60441.qmail@web27106.mail.ukl.yahoo.com> Message-ID: This problem has been fixed by the most recent update to RTCollector.m3, with respect to handling of weak references. On Jul 2, 2007, at 12:05 PM, Daniel Alejandro Benavides D. wrote: > Hi: > In LINUXLIBC6 32 bits ubuntu Dapper with PTHREAD, the > same problem is happensg, with the message of the > RTCollector > > danielb at danielb-desktop:~$ mentor > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", > line 2310 > *** > > Aborted > > danielb at danielb-desktop:~$ > > With the @M3noincremental runs fine, @M3nogc also > doesnt break. > > > > --- Tony Hosking wrote: > >> 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, > === message truncated === > > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. > http://es.voice.yahoo.com From hosking at cs.purdue.edu Mon Jul 2 22:01:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 2 Jul 2007 16:01:26 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> References: <200707021035.l62AZmO5090751@camembert.async.caltech.edu> Message-ID: Is there any chance this error is related to the fix I just made with respect to weak references? I am going to get a user-level setup working for my LINUXLIBC6 builds, so as to try and track this problem down. 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 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? From mika at async.caltech.edu Tue Jul 3 11:13:23 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 03 Jul 2007 02:13:23 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Mon, 02 Jul 2007 11:49:57 EDT." <39E88F42-57CE-4AE0-8ED8-AF955B6A0E26@cs.purdue.edu> Message-ID: <200707030913.l639DNDc012408@camembert.async.caltech.edu> Wow! It works! I am able to compile the various stages of bootstrap as well as run Juno, mentor, etc., without any @M3 hacks, on FreeBSD with the user-level threads, as of this afternoon's checkout (around 3 p.m. Pacific). On my quest to move on from various dusty PM3 decks, I am still struggling with some of my own code, which seems to be having issues with pickles, network objects, trestle, m3gdb, and a few other odds and ends, but I will return to those at a later date. All the garbage collector issues that I am aware of seem resolved on FreeBSD. A big thanks!!! Mika P.S. Tony, if you'd like a testing account on my home machine, which is running FreeBSD5.5-RELEASE/i386, just let me know. Of course I'm happy to try updating and compiling things, too. Tony Hosking writes: >In follow up to my previous message, I think I may have a simpler >fix. Can you please try the latest version of ThreadPosix.m3 that I >just checked in. Unfortunately, I don't have a user-level threads >system on which to try (Linux is broken because setjmp/longjmp use >encryption to prevent stack-smashing security exploits), and my >Solaris boxes are not available right now. > >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 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? From hosking at cs.purdue.edu Tue Jul 3 17:28:59 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Jul 2007 11:28:59 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707030913.l639DNDc012408@camembert.async.caltech.edu> References: <200707030913.l639DNDc012408@camembert.async.caltech.edu> Message-ID: <58811923-05C1-45CF-A774-DE15BABD93B5@cs.purdue.edu> Excellent! The problem was in the way the weak references implementation squirrels away traced references and hides them from the run-time system. In my digging I have also discovered that there appears to be some sort of race in the VBT code that leads to double-release of a lock. It appears not to be GC-related. Is anyone familiar enough with the VBT code to diagnose this? It always happens at the same place: #0 ThreadPThread__Die (M3_AcxOUs_lineno=167, M3_Bd56fi_msg=0x1061088) at ThreadPThread.m3:1238 #1 0x010360d7 in ThreadPThread__InnerUnlockMutex (M3_AYIbX3_m=0xb4d127c4, M3_BXP32l_self=0xb4d1e010) at ThreadPThread.m3:167 #2 0x010362ee in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0xb4d127c4) at ThreadPThread.m3:188 #3 0x004dca26 in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d127c4, M3_BFdKo9_ch=0xb4d15164, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:799 #4 0x004d51dd in VBT__Sync (M3_BJ2YpW_v=0xb4d15164, M3_AicXUJ_wait=1 '\001') at VBT.m3:1167 #5 0x00524838 in JoinedVBT__Sync (M3_B2daE0_v=0xb4d12654, M3_BFdKo9_ch=0xb4d12730, M3_AicXUJ_wait=1 '\001') at JoinedVBT.m3:101 #6 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d12730, M3_BFdKo9_ch=0xb4d126b4, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #7 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d126b4, M3_BFdKo9_ch=0xb24c5e48, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #8 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb24c5e48, M3_BFdKo9_ch=0xb4d1e0b0, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #9 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d1e0b0, M3_BFdKo9_ch=0xb4d1e31c, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #10 0x004dc9ff in VBTClass__SyncDefault (M3_Dg4CVT_v=0xb4d1e31c, M3_BFdKo9_ch=0xb4d1e1a0, M3_AicXUJ_wait=1 '\001') at VBTClass.m3:797 #11 0x004d51dd in VBT__Sync (M3_BJ2YpW_v=0xb4d1e1a0, M3_AicXUJ_wait=1 '\001') at VBT.m3:1167 #12 0x00bcc273 in MGV__MGRedisplay (M3_AdEaVQ_v=0xb4d1e1a0, M3_A0Kbc5_br=0xcf2600) at MGV.m3:146 #13 0x00bb7fa1 in Animate__DoAnimation (M3_CCfZY3_t=0xb2506534, M3_BUucNs_time=0.157132864, M3_BUucNs_timePrev=0.156615973, M3_AdEaVQ_v=0xb4d1e1a0, M3_DsL7Zz_mg=0x0) at Animate.m3:57 #14 0x00bb80eb in Animate__Do (M3_CCfZY3_t=0xb2506534, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0xb4d1e1a0, M3_BUucNs_duration=1) at Animate.m3:74 #15 0x00bcd5c6 in MGV__Animation (M3_AdEaVQ_v=0xb4d1e1a0, M3_BUucNs_duration=1) at MGV.m3:313 #16 0x0031a3f3 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0xb4d1e0b0, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at GraphVBT.m3:656 #17 0x08077aec in PackingView3__Probe (M3_ClPWAg_view=0xb24c5e48, M3_AcxOUs_bin=1, M3_BUucNs_total=0.972417712) at PackingView3.m3:68 #18 0x0806c76c in BinpackIE__OEDispatcher (M3_Ao6Rbg_v=0xb24c5e48, M3_Af40ku_evt=0xb7fda068) at BinpackIE.m3:96 #19 0x001f83fb in Zeus__ViewThread (M3_BH3Tll_self=0xb4d22030) at Zeus.m3:331 #20 0x01038d80 in ThreadPThread__RunThread (M3_EkbOya_me=0x84c5b98) at ThreadPThread.m3:547 #21 0x01038895 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x84c5b98) at ThreadPThread.m3:517 #22 0x42a2a3db in start_thread () from /lib/libpthread.so.0 #23 0x4296f26e in clone () from /lib/libc.so.6 On Jul 3, 2007, at 5:13 AM, Mika Nystrom wrote: > > Wow! It works! I am able to compile the various stages of bootstrap > as well as run Juno, mentor, etc., without any @M3 hacks, on FreeBSD > with the user-level threads, as of this afternoon's checkout (around > 3 p.m. Pacific). On my quest to move on from various dusty PM3 > decks, I am still struggling with some of my own code, which seems > to be having issues with pickles, network objects, trestle, m3gdb, > and a few other odds and ends, but I will return to those at a later > date. All the garbage collector issues that I am aware of seem > resolved on FreeBSD. A big thanks!!! > > Mika > > P.S. Tony, if you'd like a testing account on my home machine, which > is running FreeBSD5.5-RELEASE/i386, just let me know. Of course > I'm happy to try updating and compiling things, too. > > Tony Hosking writes: >> In follow up to my previous message, I think I may have a simpler >> fix. Can you please try the latest version of ThreadPosix.m3 that I >> just checked in. Unfortunately, I don't have a user-level threads >> system on which to try (Linux is broken because setjmp/longjmp use >> encryption to prevent stack-smashing security exploits), and my >> Solaris boxes are not available right now. >> >> 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 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? From hosking at cs.purdue.edu Tue Jul 3 18:42:16 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 3 Jul 2007 12:42:16 -0400 Subject: [M3devel] User-level threading Message-ID: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> I have a question that may influence the direction we take with user- level threading support. Currently, user-level threading is broken on platforms that implement secure setjmp/longjmp via encryption since hacking the jump buffers the way we currently do for user-level threading triggers longjmp errors. A better alternative is to use makecontext/getcontext/setcontext on platforms that support it. For example, I know of the following situation for the targets I track: Target System (pthreads) threads User (setjmp/longjmp) threads User (getcontext/setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES unimplemented YES (but not using makecontext) PPC_DARWIN YES NO no getcontext/setcontext I386_DARWIN YES NO no getcontext/setcontext FreeBSD NO YES unimplemented Ideally, we would implement all user-level threading using makecontext and friends, but my question is how many of our user- level threading targets actually support that API? One strategy would be to re-implement user-level threading using makecontext, etc., but fake up makecontext support, etc., on those targets that don't have it. I would hate to lose the user-level thread support just because it makes sense in some situations (e.g., embedded, uni-processor). From dragisha at m3w.org Tue Jul 3 23:37:54 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 03 Jul 2007 23:37:54 +0200 Subject: [M3devel] myId and inCritical.... Message-ID: <1183498674.9419.3.camel@faramir.m3w.org> Hallelujah! -- Dragi?a Duri? From mika at async.caltech.edu Wed Jul 4 14:10:39 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 04 Jul 2007 05:10:39 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Sun, 24 Jun 2007 10:38:34 EDT." Message-ID: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Hi again! I was able to boot the CVS head of CM3 on my Mac just fine now, using the cm3.cfg you sent me. I am still running the old OS (Panther, is it?) so I tried doing it the hard way instead of using your binaries, and I got something that works pretty well. Mentor and Juno work, at least, and that's usually a good indicator that one is on the right track... But (of course there's a "but"), I am still falling down on my very first reported bug, namely this local ktok program. I still, after all that you've done, find that it dies on an illegal instruction on the Macintosh (I am running 10.3 on a Powerbook). The problem goes away if I use either @M3nogc or @M3noincremental. The gdb backtrace is not very helpful: it says the program is crashing somewhere in a text processing module, creating an iterator on a sorted table. Sorry to do this but I am feeling a bit clueless, so if you're interested and have the time to look into it, I have set up a minimal test here: http://www.async.caltech.edu/~mika/ktok_example.tgz Unfortunately, ktok itself depends on a bunch of packages. To build this, set your CM3 environment variable to anything (1 works) and just "make" (GNU make, please). Set the DEBUGLEVEL environment variable to "10" for a bit more output (not much). The very last step (compiling package cit_parse) fails for me... Specifically, the step is: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 WELCOME! GOT TOKPARAMS! GOT TOKENS GOT SUBS! "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 4: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 Looking a bit closer: [lapdog:~/t/cit_parse/src] mika% gdb /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 Starting program: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 Reading symbols for shared libraries . done WELCOME! GOT TOKPARAMS! GOT TOKENS GOT SUBS! Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x00b111c8 in ?? () (gdb) where #0 0x00b111c8 in ?? () #1 0x000120e4 in TextSubs__Apply (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at TextSubs.m3:64 #2 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 #3 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 #4 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 #5 0x00001ecc in main (argc=4, argv=0xbffffadc, envp=0xbffffaf0) at _m3main.mc:4 (gdb) Also: PROCEDURE Apply(self: T; src: TEXT): TEXT = VAR wr := TextWr.New(); c: CHAR; ind, pos, lastFlushed: INTEGER := 0; textLen := Text.Length(src); iter: SortedTextTextTbl.Iterator; original, replacement: TEXT; key, prefix: TEXT; PROCEDURE Flush() = BEGIN Wr.PutText(wr, Text.Sub(src, lastFlushed, pos - lastFlushed)); END Flush; BEGIN WHILE pos < textLen DO c := Text.GetChar(src, pos); IF c IN self.starts THEN Debug.Out("analysing: " & Text.Sub(src, pos), 100); iter := self.tbl.iterateOrdered(); (* line 64 *) ind := pos; original := ""; REPEAT INC(ind); ... I am mystified as to why gdb would say that RTLinker__RunMainBody would be calling TextSubs__Apply. With @M3nogc or @M3noincremental, all is well... I will see if I can figure out more, but this problem just doesn't seem to want to go away. To the best of my knowledge, ktok doesn't use any UNSAFE code (outside of whatever's in libm3 of course). Mika 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: > >cd ~/cm3/scripts >./do-cm3-std.sh realclean >./do-cm3-std.sh buildship > >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 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? From wagner at elegosoft.com Wed Jul 4 17:32:12 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 4 Jul 2007 17:32:12 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> References: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Message-ID: <37423.194.138.127.36.1183563132.squirrel@mail.elegosoft.com> On Wed, July 4, 2007 2:10 pm, Mika Nystrom wrote: > Hi again! > > I was able to boot the CVS head of CM3 on my Mac just fine now, > using the cm3.cfg you sent me. I am still running the old OS > (Panther, is it?) so I tried doing it the hard way instead of using > your binaries, and I got something that works pretty well. Mentor > and Juno work, at least, and that's usually a good indicator that > one is on the right track... > > But (of course there's a "but"), I am still falling down on my very > first reported bug, namely this local ktok program. I still, after > all that you've done, find that it dies on an illegal instruction > on the Macintosh (I am running 10.3 on a Powerbook). > > The problem goes away if I use either @M3nogc or @M3noincremental. > The gdb backtrace is not very helpful: it says the program is > crashing somewhere in a text processing module, creating an iterator > on a sorted table. > > Sorry to do this but I am feeling a bit clueless, so if you're > interested and have the time to look into it, I have set up a minimal > test here: > > http://www.async.caltech.edu/~mika/ktok_example.tgz > > Unfortunately, ktok itself depends on a bunch of packages. > > To build this, set your CM3 environment variable to anything (1 > works) and just "make" (GNU make, please). Set the DEBUGLEVEL > environment variable to "10" for a bit more output (not much). The > very last step (compiling package cit_parse) fails for me... > Specifically, the step is: > > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o PRSTok.i3 > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime > error: exit 4: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o > PRSTok.i3 > > Looking a bit closer: > > [lapdog:~/t/cit_parse/src] mika% gdb > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) > Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 > Starting program: /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o > PRSTok.i3 > Reading symbols for shared libraries . done > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > > Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. > 0x00b111c8 in ?? () > (gdb) where > #0 0x00b111c8 in ?? () > #1 0x000120e4 in TextSubs__Apply (M3_CN69dV_self=0xb26434, > M3_Bd56fi_src=0xb40be0) at TextSubs.m3:64 > #2 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at > RTLinker.m3:399 > #3 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 > #4 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 > #5 0x00001ecc in main (argc=4, argv=0xbffffadc, envp=0xbffffaf0) at > _m3main.mc:4 > (gdb) > > Also: > > PROCEDURE Apply(self: T; src: TEXT): TEXT = > VAR > wr := TextWr.New(); > c: CHAR; > ind, pos, lastFlushed: INTEGER := 0; > textLen := Text.Length(src); > iter: SortedTextTextTbl.Iterator; > original, replacement: TEXT; > key, prefix: TEXT; > PROCEDURE Flush() = > BEGIN > Wr.PutText(wr, Text.Sub(src, lastFlushed, pos - lastFlushed)); > END Flush; > BEGIN > WHILE pos < textLen DO > c := Text.GetChar(src, pos); > IF c IN self.starts THEN > Debug.Out("analysing: " & Text.Sub(src, pos), 100); > iter := self.tbl.iterateOrdered(); (* line 64 *) > ind := pos; > original := ""; > REPEAT > INC(ind); > ... > > I am mystified as to why gdb would say that RTLinker__RunMainBody > would be calling TextSubs__Apply. > > With @M3nogc or @M3noincremental, all is well... > > I will see if I can figure out more, but this problem just doesn't > seem to want to go away. To the best of my knowledge, ktok doesn't > use any UNSAFE code (outside of whatever's in libm3 of course). I cannot really tell you why there's a bad instruction in some of the module initialization code, but the RT linker is executing all the module bodies in correct order at the start of the program (at least it tries to :). So probably TextSubs.Apply is called from some module initialization code. Have you tried to run the program with @M3tracelinker to get some context to that call? It should print ouy all module names... This _may_ be helpful. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From elmstb at aon.at Wed Jul 4 20:12:04 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 20:12:04 +0200 Subject: [M3devel] User-level threading In-Reply-To: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> Message-ID: <468BE2F4.7010805@aon.at> Not long ago I have fixed this problem by replacing setjmp/longjmp with my own i386 - implementations of these functions for SRC-M3. The result seems to be stable and correct. However this may be less favourable than using makecontext since the assembler routines will only work on i386 hardware. Moreover setjmp/longjmp are said that they may cause the loss of assignents, because they do not save certain registers(cx,dx) -> see "Exception semantics" at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. Nevertheless possible future changes on make/get/setcontext will not be able to affect Modula-3 when extracting the SP from the context record any more if it does not rely on glibc functions. Another solution is to link against the old glibc files (unpacked into /lib/anc): > ldd $(which m3build) linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) Please tell me if you are intereseted in any of both solutions. I would suppose a solution for CM3 not to differ that much. Yours, Elmar Stellnberger Tony Hosking wrote: > I have a question that may influence the direction we take with > user-level threading support. Currently, user-level threading is > broken on platforms that implement secure setjmp/longjmp via > encryption since hacking the jump buffers the way we currently do for > user-level threading triggers longjmp errors. A better alternative is > to use makecontext/getcontext/setcontext on platforms that support it. > For example, I know of the following situation for the targets I track: > > Target System (pthreads) threads User (setjmp/longjmp) threads User > (getcontext/setcontext) threads > > LINUXLIBC6 YES NO unimplemented > SOLgnu YES unimplemented YES (but not using makecontext) > PPC_DARWIN YES NO no getcontext/setcontext > I386_DARWIN YES NO no getcontext/setcontext > FreeBSD NO YES unimplemented > > Ideally, we would implement all user-level threading using makecontext > and friends, but my question is how many of our user-level threading > targets actually support that API? One strategy would be to > re-implement user-level threading using makecontext, etc., but fake up > makecontext support, etc., on those targets that don't have it. > > I would hate to lose the user-level thread support just because it > makes sense in some situations (e.g., embedded, uni-processor). > > > From elmstb at aon.at Wed Jul 4 20:31:50 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 20:31:50 +0200 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468BE796.8020802@aon.at> It seems to be the same message, which I have sent to you. Has there been anything new you wanted to tell me? Is the setjmp/longjmp replacement of interest? Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > However this may be less favourable than using makecontext since the > assembler routines will only work on i386 hardware. > Moreover setjmp/longjmp are said that they may cause the loss of > assignents, because they do not save certain registers(cx,dx) -> see > "Exception semantics" at > http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. > Nevertheless possible future changes on make/get/setcontext will not be > able to affect Modula-3 when extracting the SP from the context record > any more if it does not rely on glibc functions. > Another solution is to link against the old glibc files (unpacked into > /lib/anc): > > >> ldd $(which m3build) >> > linux-gate.so.1 => (0xffffe000) > libm3front.so.1 => > /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) > libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) > libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) > /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) > > Please tell me if you are intereseted in any of both solutions. > I would suppose a solution for CM3 not to differ that much. > > Yours, > Elmar Stellnberger > > > > Tony Hosking wrote: > >> I have a question that may influence the direction we take with >> user-level threading support. Currently, user-level threading is >> broken on platforms that implement secure setjmp/longjmp via >> encryption since hacking the jump buffers the way we currently do for >> user-level threading triggers longjmp errors. A better alternative is >> to use makecontext/getcontext/setcontext on platforms that support it. >> For example, I know of the following situation for the targets I track: >> >> Target System (pthreads) threads User (setjmp/longjmp) threads User >> (getcontext/setcontext) threads >> >> LINUXLIBC6 YES NO unimplemented >> SOLgnu YES unimplemented YES (but not using makecontext) >> PPC_DARWIN YES NO no getcontext/setcontext >> I386_DARWIN YES NO no getcontext/setcontext >> FreeBSD NO YES unimplemented >> >> Ideally, we would implement all user-level threading using makecontext >> and friends, but my question is how many of our user-level threading >> targets actually support that API? One strategy would be to >> re-implement user-level threading using makecontext, etc., but fake up >> makecontext support, etc., on those targets that don't have it. >> >> I would hate to lose the user-level thread support just because it >> makes sense in some situations (e.g., embedded, uni-processor). >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jul 4 22:12:47 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 4 Jul 2007 16:12:47 -0400 Subject: [M3devel] User-level threading In-Reply-To: <468BE796.8020802@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> <468BE796.8020802@aon.at> Message-ID: In looking at things again, I am more and more convinced that ThreadPosix should be implemented against the standard API for makecontext/getcontext/setcontext/swapcontext. Platforms that do not provide these will need to provide an equivalent implementation of these routines, similar to what you suggest. Right now, I know all of SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary support. On Jul 4, 2007, at 2:31 PM, Elmar Stellnberger wrote: > It seems to be the same message, which I have sent to you. > Has there been anything new you wanted to tell me? > Is the setjmp/longjmp replacement of interest? > > Elmar Stellnberger wrote: >> Not long ago I have fixed this problem by replacing setjmp/longjmp >> with my own i386 - implementations of these functions for SRC-M3. >> The result seems to be stable and correct. However this may be >> less favourable than using makecontext since the assembler >> routines will only work on i386 hardware. Moreover setjmp/longjmp >> are said that they may cause the loss of assignents, because they >> do not save certain registers(cx,dx) -> see "Exception semantics" >> at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/ >> restrictions.html. Nevertheless possible future changes on make/ >> get/setcontext will not be able to affect Modula-3 when extracting >> the SP from the context record any more if it does not rely on >> glibc functions. Another solution is to link against the old glibc >> files (unpacked into /lib/anc): >>> ldd $(which m3build) >> linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/ >> lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so. >> 6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/ >> libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) >> Please tell me if you are intereseted in any of both solutions. I >> would suppose a solution for CM3 not to differ that much. Yours, >> Elmar Stellnberger Tony Hosking wrote: >>> I have a question that may influence the direction we take with >>> user-level threading support. Currently, user-level threading is >>> broken on platforms that implement secure setjmp/longjmp via >>> encryption since hacking the jump buffers the way we currently do >>> for user-level threading triggers longjmp errors. A better >>> alternative is to use makecontext/getcontext/setcontext on >>> platforms that support it. For example, I know of the following >>> situation for the targets I track: Target System (pthreads) >>> threads User (setjmp/longjmp) threads User (getcontext/ >>> setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES >>> unimplemented YES (but not using makecontext) PPC_DARWIN YES NO >>> no getcontext/setcontext I386_DARWIN YES NO no getcontext/ >>> setcontext FreeBSD NO YES unimplemented Ideally, we would >>> implement all user-level threading using makecontext and friends, >>> but my question is how many of our user-level threading targets >>> actually support that API? One strategy would be to re-implement >>> user-level threading using makecontext, etc., but fake up >>> makecontext support, etc., on those targets that don't have it. I >>> would hate to lose the user-level thread support just because it >>> makes sense in some situations (e.g., embedded, uni-processor). > From wagner at elegosoft.com Wed Jul 4 22:25:16 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 4 Jul 2007 22:25:16 +0200 Subject: [M3devel] User-level threading In-Reply-To: References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> <468BE796.8020802@aon.at> Message-ID: <20070704202516.GA26977@elegosoft.com> On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: > In looking at things again, I am more and more convinced that > ThreadPosix should be implemented against the standard API for > makecontext/getcontext/setcontext/swapcontext. Platforms that do not > provide these will need to provide an equivalent implementation of > these routines, similar to what you suggest. Right now, I know all of > SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary > support. I think a `standard' implementation using makecontext/getcontext/... would be the best. For those platforms that do not support that, we can still use a C or assembler implementation. I would strongly vote for keeping user-level threading, too. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Wed Jul 4 23:35:13 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 Jul 2007 23:35:13 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707041210.l64CAdLp040494@camembert.async.caltech.edu> Message-ID: <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Hi: I take the sources from the your web page and type make on the top of the directory v and end in this message: ===> cit_parse --- building in LINUXLIBC6 --- ignoring override("cit_parse", "/home/danielb/Desktop/v") /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x4000b19f *** "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 1536: /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 --procedure-- -line- -file--- exec -- _exec 20 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _xCons 37 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tCons 81 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tConsUn 82 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl Token 85 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl include_dir 3 /home/danielb/Desktop/v/cit_parse/src/m3makefile 5 /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args Fatal Error: package build failed Well that was because of the lack of the file PRS.t Searching I noticed that the file is in v/cit_parse/src/PRS.t and made a copy on v/parserlib/ktok/src directory Then try make again and but this time, get this: cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e new source -> compiling PRSTok.m3 "../LINUXLIBC6/PRSTok.m3", line 1: syntax error: missing INTERFACE or MODULE keyword "../LINUXLIBC6/PRSTok.m3", line 1: unable to find interface () "../LINUXLIBC6/PRSTok.m3", line 1: warning: file name (PRSTok.m3) doesn't match module name () 2 errors and 1 warning encountered new source -> compiling PRSTok.i3 new source -> compiling PRSLex.i3 new source -> compiling PRSLex.m3 new source -> compiling PRSParse.i3 new source -> compiling PRSParse.m3 new source -> compiling PRSLexStd.i3 new source -> compiling PRSLexStd.m3 new source -> compiling PRSParseStd.i3 new source -> compiling PRSParseStd.m3 new source -> compiling CHPTok.i3 new source -> compiling CHPTok.m3 "../LINUXLIBC6/CHPTok.m3", line 36: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered new source -> compiling CHPLex.i3 new source -> compiling CHPLex.m3 new source -> compiling CHPParse.i3 new source -> compiling CHPParse.m3 new source -> compiling CHPLexStd.i3 new source -> compiling CHPLexStd.m3 new exporters -> recompiling PRSTok.i3 compilation failed => not building library "libcit_parse.a" Fatal Error: package build failed danielb at danielb-desktop:~/code/caltech-parser/v2/v$ It seems PRSTok.m3 does exist on v/cit_parse/LINUXLIBC6 but is an empty file. Maybe Im not doing the right steps? Thanks --- Mika Nystrom wrote: > Hi again! > > I was able to boot the CVS head of CM3 on my Mac > just fine now, > using the cm3.cfg you sent me. I am still running > the old OS > (Panther, is it?) so I tried doing it the hard way > instead of using > your binaries, and I got something that works pretty > well. Mentor > and Juno work, at least, and that's usually a good > indicator that > one is on the right track... > > But (of course there's a "but"), I am still falling > down on my very > first reported bug, namely this local ktok program. > I still, after > all that you've done, find that it dies on an > illegal instruction > on the Macintosh (I am running 10.3 on a Powerbook). > > The problem goes away if I use either @M3nogc or > @M3noincremental. > The gdb backtrace is not very helpful: it says the > program is > crashing somewhere in a text processing module, > creating an iterator > on a sorted table. > > Sorry to do this but I am feeling a bit clueless, so > if you're > interested and have the time to look into it, I have > set up a minimal > test here: > > http://www.async.caltech.edu/~mika/ktok_example.tgz > > Unfortunately, ktok itself depends on a bunch of > packages. > > To build this, set your CM3 environment variable to > anything (1 > works) and just "make" (GNU make, please). Set the > DEBUGLEVEL > environment variable to "10" for a bit more output > (not much). The > very last step (compiling package cit_parse) fails > for me... > Specifically, the step is: > > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", > line 20: quake runtime error: exit 4: > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > > Looking a bit closer: > > [lapdog:~/t/cit_parse/src] mika% gdb > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri > Jul 16 21:42:28 GMT 2004) > Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 > Starting program: > /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok > ../src/PRS.t -o PRSTok.i3 > Reading symbols for shared libraries . done > WELCOME! > GOT TOKPARAMS! > GOT TOKENS > GOT SUBS! > > Program received signal EXC_BAD_INSTRUCTION, Illegal > instruction/operand. > 0x00b111c8 in ?? () > (gdb) where > #0 0x00b111c8 in ?? () > #1 0x000120e4 in TextSubs__Apply > (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at > TextSubs.m3:64 > #2 0x0005b15c in RTLinker__RunMainBody > (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 > #3 0x00059f20 in RTLinker__AddUnitI > (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 > #4 0x0005a01c in RTLinker__AddUnit > (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 > #5 0x00001ecc in main (argc=4, argv=0xbffffadc, > envp=0xbffffaf0) at _m3main.mc:4 > (gdb) > > Also: > > PROCEDURE Apply(self: T; src: TEXT): TEXT = > VAR > wr := TextWr.New(); > c: CHAR; > ind, pos, lastFlushed: INTEGER := 0; > textLen := Text.Length(src); > iter: SortedTextTextTbl.Iterator; > original, replacement: TEXT; > key, prefix: TEXT; > PROCEDURE Flush() = > BEGIN > Wr.PutText(wr, Text.Sub(src, lastFlushed, pos > - lastFlushed)); > END Flush; > BEGIN > WHILE pos < textLen DO > c := Text.GetChar(src, pos); > IF c IN self.starts THEN > Debug.Out("analysing: " & Text.Sub(src, > pos), 100); > iter := self.tbl.iterateOrdered(); (* line > 64 *) > ind := pos; > original := ""; > REPEAT > INC(ind); > ... > > I am mystified as to why gdb would say that > RTLinker__RunMainBody > would be calling TextSubs__Apply. > > With @M3nogc or @M3noincremental, all is well... > > I will see if I can figure out more, but this > problem just doesn't > seem to want to go away. To the best of my > knowledge, ktok doesn't > use any UNSAFE code (outside of whatever's in libm3 > of course). > > Mika > > 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 > === message truncated === ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome From dabenavidesd at yahoo.es Wed Jul 4 23:40:34 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 4 Jul 2007 23:40:34 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Message-ID: <20070704214034.90770.qmail@web27105.mail.ukl.yahoo.com> Sorry the last message was too long and I think was cutted by the mailer. Hi: I take the sources from the your web page and type make on the top of the directory v and end in this message: ===> cit_parse --- building in LINUXLIBC6 --- ignoring override("cit_parse", "/home/danielb/Desktop/v") /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x4000b19f *** "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", line 20: quake runtime error: exit 1536: /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok ../src/PRS.t -o PRSTok.i3 --procedure-- -line- -file--- exec -- _exec 20 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _xCons 37 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tCons 81 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl _tConsUn 82 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl Token 85 /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl include_dir 3 /home/danielb/Desktop/v/cit_parse/src/m3makefile 5 /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args Fatal Error: package build failed Well that was because of the lack of the file PRS.t Searching I noticed that the file is in v/cit_parse/src/PRS.t and made a copy on v/parserlib/ktok/src directory Then try make again and but this time, get this: cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . cp /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y . /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e /home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext ../src/CHPLexStd.e new source -> compiling PRSTok.m3 "../LINUXLIBC6/PRSTok.m3", line 1: syntax error: missing INTERFACE or MODULE keyword "../LINUXLIBC6/PRSTok.m3", line 1: unable to find interface () "../LINUXLIBC6/PRSTok.m3", line 1: warning: file name (PRSTok.m3) doesn't match module name () 2 errors and 1 warning encountered new source -> compiling PRSTok.i3 new source -> compiling PRSLex.i3 new source -> compiling PRSLex.m3 new source -> compiling PRSParse.i3 new source -> compiling PRSParse.m3 new source -> compiling PRSLexStd.i3 new source -> compiling PRSLexStd.m3 new source -> compiling PRSParseStd.i3 new source -> compiling PRSParseStd.m3 new source -> compiling CHPTok.i3 new source -> compiling CHPTok.m3 "../LINUXLIBC6/CHPTok.m3", line 36: warning: potentially unhandled exception: RTAllocator.OutOfMemory 1 warning encountered new source -> compiling CHPLex.i3 new source -> compiling CHPLex.m3 new source -> compiling CHPParse.i3 new source -> compiling CHPParse.m3 new source -> compiling CHPLexStd.i3 new source -> compiling CHPLexStd.m3 new exporters -> recompiling PRSTok.i3 compilation failed => not building library "libcit_parse.a" Fatal Error: package build failed danielb at danielb-desktop:~/code/caltech-parser/v2/v$ It seems PRSTok.m3 does exist on v/cit_parse/LINUXLIBC6 but is an empty file. Maybe Im not doing the right steps? Thanks --- "Daniel Alejandro Benavides D." escribi?: > Hi: > I take the sources from the your web page and type > make on the top of the directory v and end in this > message: > > ===> cit_parse > --- building in LINUXLIBC6 --- > > ignoring override("cit_parse", > "/home/danielb/Desktop/v") > > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to > dereference NIL > *** pc = 0x4000b19f > *** > > "/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", > line 20: quake runtime error: exit 1536: > /home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > ../src/PRS.t -o PRSTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 20 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _xCons 37 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _tCons 81 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > _tConsUn 82 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > Token 85 > /home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > include_dir 3 > /home/danielb/Desktop/v/cit_parse/src/m3makefile > 5 > /home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > > Well that was because of the lack of the file PRS.t > > Searching I noticed that the file is in > v/cit_parse/src/PRS.t and made a copy on > v/parserlib/ktok/src directory > Then try make again and but this time, get this: > > cp > /home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome From mika at async.caltech.edu Thu Jul 5 14:48:46 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 05 Jul 2007 05:48:46 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Wed, 04 Jul 2007 23:35:13 +0200." <20070704213513.79496.qmail@web27112.mail.ukl.yahoo.com> Message-ID: <200707051248.l65Cmk7b064556@camembert.async.caltech.edu> Hi Daniel, Thanks for helping look into this. Could you send me a gdb stack trace or something along those lines of the segmentation violation? It doesn't have to be m3gdb, normal gdb would do fine. The PRS.t file isn't missing. What you're seeing is ktok being run with a CWD of /home/danielb/Desktop/v/cit_parse/LINUXLIBC6 , so PRS.t is indeed "../src/PRS.t". The reason the file is empty in the last example is that that's what had been generated by the time the ktok program crashed. That's exactly what I get on my Mac, except the program crashes on an illegal instruction, not a segfault. Of course it works fine on PM3, both Windows and Unix, and older versions of CM3... I'm sure there's some kind of bug in ktok, too. Mika "Daniel Alejandro Benavides D." writes: >Hi: >I take the sources from the your web page and type >make on the top of the directory v and end in this >message: > >===> cit_parse >--- building in LINUXLIBC6 --- > >ignoring override("cit_parse", >"/home/danielb/Desktop/v") > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to >dereference NIL >*** pc = 0x4000b19f >*** > >"/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", >line 20: quake runtime error: exit 1536: >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok >../src/PRS.t -o PRSTok.i3 > >--procedure-- -line- -file--- >exec -- >_exec 20 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_xCons 37 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_tCons 81 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >_tConsUn 82 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >Token 85 >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl >include_dir 3 >/home/danielb/Desktop/v/cit_parse/src/m3makefile > 5 >/home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > >Fatal Error: package build failed > >Well that was because of the lack of the file PRS.t > >Searching I noticed that the file is in >v/cit_parse/src/PRS.t and made a copy on >v/parserlib/ktok/src directory >Then try make again and but this time, get this: > >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y >. >cp >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y >. >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext >../src/CHPLexStd.e >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext >../src/CHPLexStd.e >new source -> compiling PRSTok.m3 >"../LINUXLIBC6/PRSTok.m3", line 1: syntax error: >missing INTERFACE or MODULE keyword >"../LINUXLIBC6/PRSTok.m3", line 1: unable to find >interface () >"../LINUXLIBC6/PRSTok.m3", line 1: warning: file name >(PRSTok.m3) doesn't match module name () >2 errors and 1 warning encountered >new source -> compiling PRSTok.i3 >new source -> compiling PRSLex.i3 >new source -> compiling PRSLex.m3 >new source -> compiling PRSParse.i3 >new source -> compiling PRSParse.m3 >new source -> compiling PRSLexStd.i3 >new source -> compiling PRSLexStd.m3 >new source -> compiling PRSParseStd.i3 >new source -> compiling PRSParseStd.m3 >new source -> compiling CHPTok.i3 >new source -> compiling CHPTok.m3 >"../LINUXLIBC6/CHPTok.m3", line 36: warning: >potentially unhandled exception: >RTAllocator.OutOfMemory >1 warning encountered >new source -> compiling CHPLex.i3 >new source -> compiling CHPLex.m3 >new source -> compiling CHPParse.i3 >new source -> compiling CHPParse.m3 >new source -> compiling CHPLexStd.i3 >new source -> compiling CHPLexStd.m3 >new exporters -> recompiling PRSTok.i3 >compilation failed => not building library >"libcit_parse.a" >Fatal Error: package build failed > >danielb at danielb-desktop:~/code/caltech-parser/v2/v$ > > >It seems PRSTok.m3 does exist on >v/cit_parse/LINUXLIBC6 but is an empty file. > >Maybe Im not doing the right steps? > >Thanks > > > > >--- Mika Nystrom wrote: > >> Hi again! >> >> I was able to boot the CVS head of CM3 on my Mac >> just fine now, >> using the cm3.cfg you sent me. I am still running >> the old OS >> (Panther, is it?) so I tried doing it the hard way >> instead of using >> your binaries, and I got something that works pretty >> well. Mentor >> and Juno work, at least, and that's usually a good >> indicator that >> one is on the right track... >> >> But (of course there's a "but"), I am still falling >> down on my very >> first reported bug, namely this local ktok program. >> I still, after >> all that you've done, find that it dies on an >> illegal instruction >> on the Macintosh (I am running 10.3 on a Powerbook). >> >> The problem goes away if I use either @M3nogc or >> @M3noincremental. >> The gdb backtrace is not very helpful: it says the >> program is >> crashing somewhere in a text processing module, >> creating an iterator >> on a sorted table. >> >> Sorry to do this but I am feeling a bit clueless, so >> if you're >> interested and have the time to look into it, I have >> set up a minimal >> test here: >> >> http://www.async.caltech.edu/~mika/ktok_example.tgz >> >> Unfortunately, ktok itself depends on a bunch of >> packages. >> >> To build this, set your CM3 environment variable to >> anything (1 >> works) and just "make" (GNU make, please). Set the >> DEBUGLEVEL >> environment variable to "10" for a bit more output >> (not much). The >> very last step (compiling package cit_parse) fails >> for me... >> Specifically, the step is: >> >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> WELCOME! >> GOT TOKPARAMS! >> GOT TOKENS >> GOT SUBS! >> "/Users/mika/t/parserlib/parserlib/src/parser.tmpl", >> line 20: quake runtime error: exit 4: >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> >> Looking a bit closer: >> >> [lapdog:~/t/cit_parse/src] mika% gdb >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri >> Jul 16 21:42:28 GMT 2004) >> Copyright 2003 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 ../src/PRS.t -o PRSTok.i3 >> Starting program: >> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok >> ../src/PRS.t -o PRSTok.i3 >> Reading symbols for shared libraries . done >> WELCOME! >> GOT TOKPARAMS! >> GOT TOKENS >> GOT SUBS! >> >> Program received signal EXC_BAD_INSTRUCTION, Illegal >> instruction/operand. >> 0x00b111c8 in ?? () >> (gdb) where >> #0 0x00b111c8 in ?? () >> #1 0x000120e4 in TextSubs__Apply >> (M3_CN69dV_self=0xb26434, M3_Bd56fi_src=0xb40be0) at >> TextSubs.m3:64 >> #2 0x0005b15c in RTLinker__RunMainBody >> (M3_DjPxE3_m=0xad190) at RTLinker.m3:399 >> #3 0x00059f20 in RTLinker__AddUnitI >> (M3_DjPxE3_m=0xad190) at RTLinker.m3:113 >> #4 0x0005a01c in RTLinker__AddUnit >> (M3_DjPxE5_b=0x3520) at RTLinker.m3:122 >> #5 0x00001ecc in main (argc=4, argv=0xbffffadc, >> envp=0xbffffaf0) at _m3main.mc:4 >> (gdb) >> >> Also: >> >> PROCEDURE Apply(self: T; src: TEXT): TEXT = >> VAR >> wr := TextWr.New(); >> c: CHAR; >> ind, pos, lastFlushed: INTEGER := 0; >> textLen := Text.Length(src); >> iter: SortedTextTextTbl.Iterator; >> original, replacement: TEXT; >> key, prefix: TEXT; >> PROCEDURE Flush() = >> BEGIN >> Wr.PutText(wr, Text.Sub(src, lastFlushed, pos >> - lastFlushed)); >> END Flush; >> BEGIN >> WHILE pos < textLen DO >> c := Text.GetChar(src, pos); >> IF c IN self.starts THEN >> Debug.Out("analysing: " & Text.Sub(src, >> pos), 100); >> iter := self.tbl.iterateOrdered(); (* line >> 64 *) >> ind := pos; >> original := ""; >> REPEAT >> INC(ind); >> ... >> >> I am mystified as to why gdb would say that >> RTLinker__RunMainBody >> would be calling TextSubs__Apply. >> >> With @M3nogc or @M3noincremental, all is well... >> >> I will see if I can figure out more, but this >> problem just doesn't >> seem to want to go away. To the best of my >> knowledge, ktok doesn't >> use any UNSAFE code (outside of whatever's in libm3 >> of course). >> >> Mika >> >> 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 >> >=== message truncated === > > > > >____________________________________________________________________________________ >?Descubre una nueva forma de obtener respuestas a tus preguntas! >Entra en Yahoo! Respuestas. >http://es.answers.yahoo.com/info/welcome From rodney.bates at wichita.edu Thu Jul 5 15:35:31 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 05 Jul 2007 08:35:31 -0500 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468CF3A3.2090707@wichita.edu> Could you make your replacement setjmp/longjmp available for those of us who are still maintaining old PM3 implementations? This would be a great help. Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From dabenavidesd at yahoo.es Thu Jul 5 20:46:21 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 5 Jul 2007 20:46:21 +0200 (CEST) Subject: [M3devel] strange errors... In-Reply-To: <200707051248.l65Cmk7b064556@camembert.async.caltech.edu> Message-ID: <20070705184621.73160.qmail@web27113.mail.ukl.yahoo.com> Hi Mika: What I get here executing is sometimes an Illegal intruction or Floating point exception (I guess OS message when executing the program) or the CM3 runtime error message. Well I debugged a time and I got it breaks inside RTType.m3, but m3gdb process ends, besides the tok process. (m3gdb) where #0 FindType (id=995871772) at RTType.m3:137 #1 0x0809afb6 in ScanTypecase (ref=16_b7eeb0cc, x=16_0815d844) at RTType.m3:123 #2 0x080b2bdf in Sub (t=16_b7eeb0cc, start=0, length=10) at TextSub.m3:35 #3 0x0804a6ba in Base (t=16_b7eeb0cc, suffix=16_081397a8) at TokParams.m3:22 #4 0x0804a700 in SetBaseFrom (t=16_b7eeb0cc, suffix=16_081397a8) at TokParams.m3:40 #5 0x0804ab74 in Get (progName=16_08139798, inSuffix=16_081397a8, outSuffix=16_081397b8, specifyTok=FALSE, _result= RECORD source = NIL; out = NIL; tokSource = NIL; tokOut = NIL; outBase = NIL; tokOutBase = NIL; END) at TokParams.m3:63 #6 0x08049011 in Main (mode=1) at Main.m3:92 #7 0x080949d9 in RunMainBody (m=16_081504e0) at RTLinker.m3:399 #8 0x0809347e in AddUnitI (m=16_081504e0) at RTLinker.m3:113 #9 0x08093507 in AddUnit (b={"Main_M3", Declared at: Main.m3:90}) at RTLinker.m3:122 #10 0x08048217 in main (argc=4, argv=0xbf921b64, envp=0xbf921b78) at _m3main.mc:4 (m3gdb) step FindType (id=4) at RTType.m3:138 138 in RTType.m3 (m3gdb) step Segmentation fault danielb at danielb-desktop:~/code/caltech-parser/v/cit_parse/LINUXLIBC6$ *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0xb7eef1e7 *** danielb at danielb-desktop:~/code/caltech-parser/v/cit_parse/LINUXLIBC6$ Any more helpful? Bye --- Mika Nystrom wrote: > Hi Daniel, > > Thanks for helping look into this. Could you send > me a gdb stack > trace or something along those lines of the > segmentation violation? > It doesn't have to be m3gdb, normal gdb would do > fine. > > The PRS.t file isn't missing. What you're seeing is > ktok being run > with a CWD of > /home/danielb/Desktop/v/cit_parse/LINUXLIBC6 , so > PRS.t is indeed "../src/PRS.t". > > The reason the file is empty in the last example is > that that's > what had been generated by the time the ktok program > crashed. That's > exactly what I get on my Mac, except the program > crashes on an > illegal instruction, not a segfault. Of course it > works fine on > PM3, both Windows and Unix, and older versions of > CM3... I'm sure > there's some kind of bug in ktok, too. > > Mika > > > > "Daniel Alejandro Benavides D." writes: > >Hi: > >I take the sources from the your web page and type > >make on the top of the directory v and end in this > >message: > > > >===> cit_parse > >--- building in LINUXLIBC6 --- > > > >ignoring override("cit_parse", > >"/home/danielb/Desktop/v") > > > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > > > > > >*** > >*** runtime error: > >*** Segmentation violation - possible attempt to > >dereference NIL > >*** pc = 0x4000b19f > >*** > > > >"/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl", > >line 20: quake runtime error: exit 1536: > >/home/danielb/Desktop/v/parserlib/ktok/LINUXLIBC6/tok > >../src/PRS.t -o PRSTok.i3 > > > >--procedure-- -line- -file--- > >exec -- > >_exec 20 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_xCons 37 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_tCons 81 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >_tConsUn 82 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >Token 85 > >/home/danielb/Desktop/v/parserlib/parserlib/src/parser.tmpl > >include_dir 3 > >/home/danielb/Desktop/v/cit_parse/src/m3makefile > > 5 > >/home/danielb/Desktop/v/cit_parse/LINUXLIBC6/m3make.args > > > >Fatal Error: package build failed > > > >Well that was because of the lack of the file PRS.t > > > >Searching I noticed that the file is in > >v/cit_parse/src/PRS.t and made a copy on > >v/parserlib/ktok/src directory > >Then try make again and but this time, get this: > > > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.t > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.l > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y > >. > >cp > >/home/danielb/code/caltech-parser/v2/v/cit_parse/LINUXLIBC6/../src/CHP.y > >. > >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext > >../src/CHPLexStd.e > >/home/danielb/code/caltech-parser/v2/v/parserlib/kext/LINUXLIBC6/ext > >../src/CHPLexStd.e > >new source -> compiling PRSTok.m3 > >"../LINUXLIBC6/PRSTok.m3", line 1: syntax error: > >missing INTERFACE or MODULE keyword > >"../LINUXLIBC6/PRSTok.m3", line 1: unable to find > >interface () > >"../LINUXLIBC6/PRSTok.m3", line 1: warning: file > name > >(PRSTok.m3) doesn't match module name ( id>) > >2 errors and 1 warning encountered > >new source -> compiling PRSTok.i3 > >new source -> compiling PRSLex.i3 > >new source -> compiling PRSLex.m3 > >new source -> compiling PRSParse.i3 > >new source -> compiling PRSParse.m3 > >new source -> compiling PRSLexStd.i3 > >new source -> compiling PRSLexStd.m3 > >new source -> compiling PRSParseStd.i3 > >new source -> compiling PRSParseStd.m3 > >new source -> compiling CHPTok.i3 > >new source -> compiling CHPTok.m3 > >"../LINUXLIBC6/CHPTok.m3", line 36: warning: > >potentially unhandled exception: > >RTAllocator.OutOfMemory > >1 warning encountered > >new source -> compiling CHPLex.i3 > >new source -> compiling CHPLex.m3 > >new source -> compiling CHPParse.i3 > >new source -> compiling CHPParse.m3 > >new source -> compiling CHPLexStd.i3 > >new source -> compiling CHPLexStd.m3 > >new exporters -> recompiling PRSTok.i3 > >compilation failed => not building library > >"libcit_parse.a" > >Fatal Error: package build failed > > > >danielb at danielb-desktop:~/code/caltech-parser/v2/v$ > > > > > > >It seems PRSTok.m3 does exist on > >v/cit_parse/LINUXLIBC6 but is an empty file. > > > >Maybe Im not doing the right steps? > > > >Thanks > > > > > > > > > >--- Mika Nystrom wrote: > > > >> Hi again! > >> > >> I was able to boot the CVS head of CM3 on my Mac > >> just fine now, > >> using the cm3.cfg you sent me. I am still > running > >> the old OS > >> (Panther, is it?) so I tried doing it the hard > way > >> instead of using > >> your binaries, and I got something that works > pretty > >> well. Mentor > >> and Juno work, at least, and that's usually a > good > >> indicator that > >> one is on the right track... > >> > >> But (of course there's a "but"), I am still > falling > >> down on my very > >> first reported bug, namely this local ktok > program. > >> I still, after > >> all that you've done, find that it dies on an > >> illegal instruction > >> on the Macintosh (I am running 10.3 on a > Powerbook). > >> > >> The problem goes away if I use either @M3nogc or > >> @M3noincremental. > >> The gdb backtrace is not very helpful: it says > the > >> program is > >> crashing somewhere in a text processing module, > >> creating an iterator > >> on a sorted table. > >> > >> Sorry to do this but I am feeling a bit clueless, > so > === message truncated === ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. http://es.voice.yahoo.com From dragisha at m3w.org Tue Jul 10 22:46:40 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 10 Jul 2007 22:46:40 +0200 Subject: [M3devel] revevrsed EXTERNAL, almotht :) Message-ID: <1184100400.29933.3.camel@faramir.m3w.org> Can I make Modula-3 procedure, or even better - Main_M3 to be called other than that in object code? -- Dragi?a Duri? From lemming at henning-thielemann.de Wed Jul 11 13:49:34 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Jul 2007 13:49:34 +0200 (MEST) Subject: [M3devel] revevrsed EXTERNAL, almotht :) In-Reply-To: <1184100400.29933.3.camel@faramir.m3w.org> References: <1184100400.29933.3.camel@faramir.m3w.org> Message-ID: On Tue, 10 Jul 2007, [UTF-8] Dragi??a Duri?^G wrote: > Can I make Modula-3 procedure, or even better - Main_M3 to be called > other than that in object code? Do you mean the CALLBACK pragma? From dragisha at m3w.org Wed Jul 11 18:02:34 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 11 Jul 2007 18:02:34 +0200 Subject: [M3devel] revevrsed EXTERNAL, almotht :) In-Reply-To: References: <1184100400.29933.3.camel@faramir.m3w.org> Message-ID: <1184169754.2424.4.camel@faramir.m3w.org> I think not. What I need for Modula-3 program to be loaded (ie initialized) as a .so is true C procedure entry point, trivial to write in C so there is no need to force CM3 to make one of Modula-3 procedures known by "external" name. Standard _m3main execution flow has to be split in two parts and executed from this C "stub". Calling conventions are possible another problem. I don't think there would be one under *nix, and for Windows - it's a todo :). On Wed, 2007-07-11 at 13:49 +0200, Henning Thielemann wrote: > On Tue, 10 Jul 2007, [UTF-8] Dragi?a Duri^G wrote: > > > Can I make Modula-3 procedure, or even better - Main_M3 to be called > > other than that in object code? > > Do you mean the CALLBACK pragma? -- Dragi?a Duri? From wagner at elegosoft.com Fri Jul 13 09:33:58 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 13 Jul 2007 09:33:58 +0200 (CEST) Subject: [M3devel] http://llvm.org/ as M3 backend; was: Re: Why? In-Reply-To: <12678.1184263773@sa.vix.com> References: <0W2kg.46558$4L1.20223@newssvr11.news.prodigy.com> <87mzcft02e.fsf@thalassa.informatimago.com> <4foappF1k1snbU1@individual.net> <4gde82F1lsi14U1@individual.net> <4gh9gfF1neuiuU1@individual.net> <4grqp3F1obofbU1@individual.net> <12678.1184263773@sa.vix.com> Message-ID: <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> On Thu, July 12, 2007 20:09, Paul Vixie wrote: > has anyone investigated http://llvm.org/ as a potential new M3 backend? I don't think so, but the first paragraphs on the front page sound promising. I'll cc this to the m3devel list to see if anybody knows more or is interested. Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Jul 13 17:43:01 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 13 Jul 2007 10:43:01 -0500 Subject: [M3devel] CVS deprecated info strings? Message-ID: <46979D85.3060001@wichita.edu> I just got this message from CVS: cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. I am guessing this refers to stylized comments in the file(s) I committed. Any pointers to documentation on what CVS really wants here? The files are all part of m3gdb, and no doubt contain things from very long ago. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jdp at polstra.com Fri Jul 13 17:51:31 2007 From: jdp at polstra.com (John Polstra) Date: Fri, 13 Jul 2007 08:51:31 -0700 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <46979F83.4070301@polstra.com> Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts > to use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. > Any pointers to documentation on what CVS really wants here? The files are > all part of m3gdb, and no doubt contain things from very long ago. I'm just guessing, but this sounds more like a complaint from the perl scripts in the repository's CVSROOT directory. Maybe somebody updated the perl installation on the repository host, deprecating some feature that the scripts use. John From hosking at cs.purdue.edu Fri Jul 13 18:05:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 13 Jul 2007 12:05:28 -0400 Subject: [M3devel] http://llvm.org/ as M3 backend; was: Re: Why? In-Reply-To: <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> References: <0W2kg.46558$4L1.20223@newssvr11.news.prodigy.com> <87mzcft02e.fsf@thalassa.informatimago.com> <4foappF1k1snbU1@individual.net> <4gde82F1lsi14U1@individual.net> <4gh9gfF1neuiuU1@individual.net> <4grqp3F1obofbU1@individual.net> <12678.1184263773@sa.vix.com> <56335.194.138.127.36.1184312038.squirrel@mail.elegosoft.com> Message-ID: <099535B8-2C0A-4345-BF35-CBA02EC75F2C@cs.purdue.edu> I've had a little contact with some of the llvm team re M3, but forget now who that was. Certainly, I think it would be fun to do an M3CG->LLVM backend. On Jul 13, 2007, at 3:33 AM, Olaf Wagner wrote: > On Thu, July 12, 2007 20:09, Paul Vixie wrote: >> has anyone investigated http://llvm.org/ as a potential new M3 >> backend? > > I don't think so, but the first paragraphs on the front page sound > promising. I'll cc this to the m3devel list to see if anybody knows > more or is interested. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 > Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From stsp at elego.de Fri Jul 13 18:15:15 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 13 Jul 2007 18:15:15 +0200 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <20070713161515.GC98227@ted.stsp.lan> On Fri, Jul 13, 2007 at 10:43:01AM -0500, Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts to > use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. No. It's a known issue. > Any pointers to documentation on what CVS really wants here? http://ximbiot.com/cvs/manual/cvs-1.12.6/cvs_18.html#SEC168 -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mika at async.caltech.edu Mon Jul 16 03:53:11 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 18:53:11 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Mon, 02 Jul 2007 11:03:42 EDT." Message-ID: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> 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! 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 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? From hosking at cs.purdue.edu Mon Jul 16 05:39:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Jul 2007 23:39:26 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> References: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> Message-ID: <9E796D22-3940-4FB8-9B5B-F17D4648DF56@cs.purdue.edu> 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! > > 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"))); Where does the variable 'wr' come from? It is this 'wr' that is failing the assert. It should not be gray, assuming that the GC was able to find it. Can I see your Main.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 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? From hosking at cs.purdue.edu Mon Jul 16 05:41:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 15 Jul 2007 23:41:31 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> References: <200707160153.l6G1rChc099802@camembert.async.caltech.edu> Message-ID: 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 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? From mika at async.caltech.edu Mon Jul 16 05:51:33 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 20:51:33 -0700 Subject: [M3devel] strange errors... In-Reply-To: Your message of "Sun, 15 Jul 2007 23:39:26 EDT." <9E796D22-3940-4FB8-9B5B-F17D4648DF56@cs.purdue.edu> Message-ID: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> Tony Hosking writes: ... >> >> Line 113 in Main.m3 is: >> >> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); > >Where does the variable 'wr' come from? It is this 'wr' that is >failing the assert. It should not be gray, assuming that the GC was >able to find it. Can I see your Main.m3? > It fails exactly the same way with @M3paranoidgc. wr comes from FileWr.Open. The programmer has re-used wr for two open FileWrs... I marked line 113, where it crashes: (* Copyright (c) 2000 California Institute of Technology *) (* All rights reserved. See the file COPYRIGHT for a full description. *) (* $Id: Main.m3,v 1.3 2002/12/11 08:54:53 kp Exp $ *) MODULE Main; IMPORT Debug; IMPORT tokformBundle, Bundle; IMPORT TokParams; IMPORT TokSpec; IMPORT FileWr, Wr, Thread, OSError; IMPORT TextWr; IMPORT TextSubs; IMPORT TextList; IMPORT Pathname; IMPORT Fmt; IMPORT FmtTable; (* IMPORT Term; *) <* FATAL Thread.Alerted, Wr.Failure *> VAR Form := tokformBundle.Get(); PROCEDURE FormatTypes(t: TextList.T; tokName, kind: TEXT): TEXT = VAR wr := TextWr.New(); cur := t; subs: TextSubs.T; BEGIN WHILE cur # NIL DO subs := NEW(TextSubs.T).init(); subs.add("%type", cur.head); subs.add("%tok", tokName); Wr.PutText(wr, subs.apply(Bundle.Get(Form, kind))); cur := cur.tail; END; RETURN TextWr.ToText(wr); END FormatTypes; PROCEDURE FormatLegalConst(tok: TokSpec.T): TEXT = VAR dummy: TEXT; fmt := NEW(FmtTable.T).init(); BEGIN FOR i := 1 TO tok.lastConstCode DO IF tok.constTokensR.get(i, dummy) THEN fmt.putInt(i); END; END; RETURN fmt.toText(); END FormatLegalConst; PROCEDURE FormatNamedConst(tok: TokSpec.T): TEXT = VAR cur := tok.tokens; name: TEXT; code: INTEGER; wr := TextWr.New(); BEGIN WHILE cur # NIL DO name := cur.head; IF tok.constTokens.get(name, code) THEN Wr.PutText(wr, " " & name & " = " & Fmt.Int(code) & ";\n"); END; cur := cur.tail; END; RETURN TextWr.ToText(wr); END FormatNamedConst; PROCEDURE Subs(tok: TokSpec.T; name: TEXT): TextSubs.T = VAR subs := NEW(TextSubs.T).init(); BEGIN subs.add("\\\n", ""); subs.add("%tok", name); subs.add("%type", FormatTypes(tok.varTokens, name, "tokform.type")); subs.add("%case", FormatTypes(tok.varTokens, name, "tokform.case")); subs.add("%constSet", FormatLegalConst(tok)); subs.add("%constName", FormatNamedConst(tok)); subs.add("%lastConst", Fmt.Int(tok.lastConstCode)); subs.add("%gen", "(* Generated by ktok *)"); RETURN subs; END Subs; VAR tp: TokParams.T; tok: TokSpec.T; subs: TextSubs.T; wr: Wr.T; BEGIN Debug.S("WELCOME!"); tp := TokParams.Get("tok", ".t", "Tok.i3", FALSE); Debug.S("GOT TOKPARAMS!"); tok := TokParams.ReadTokens(tp); Debug.S("GOT TOKENS"); subs := Subs(tok, tp.outBase); Debug.S("GOT SUBS!"); TRY wr := FileWr.Open(tp.out); EXCEPT OSError.E => Debug.Error("Cannot open tok interface output file: " & tp.out); END; Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.i3"))); Wr.Close(wr); TRY wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3")); EXCEPT OSError.E => Debug.Error("Cannot open tok implementation output file: " & Pathname.ReplaceExt(tp.out, "m3")); END; Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); (* line 113 *) Wr.Close(wr); END Main. From mika at async.caltech.edu Mon Jul 16 06:50:52 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 21:50:52 -0700 Subject: [M3devel] User-level threading In-Reply-To: Your message of "Wed, 04 Jul 2007 22:25:16 +0200." <20070704202516.GA26977@elegosoft.com> Message-ID: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Olaf Wagner writes: >On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: >> In looking at things again, I am more and more convinced that >> ThreadPosix should be implemented against the standard API for >> makecontext/getcontext/setcontext/swapcontext. Platforms that do not >> provide these will need to provide an equivalent implementation of >> these routines, similar to what you suggest. Right now, I know all of >> SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary >> support. > >I think a `standard' implementation using makecontext/getcontext/... >would be the best. For those platforms that do not support that, >we can still use a C or assembler implementation. > >I would strongly vote for keeping user-level threading, too. Wouldn't the ideal be to have a mixed system, where N user-level threads run inside M <= N, M \approx NCPUS Pthreads? Anyone who thinks user-level threads are unnecessary should try the following program, which runs just fine under user-level threads on FreeBSD, and locks up horrendously after running about 4% of the way on Darwin/Pthreads... Mika MODULE Main; IMPORT Thread; IMPORT Rd, Stdio, Wr, Random, Fmt; TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; PROCEDURE A(cl : Cl) : REFANY = VAR rand := NEW(Random.Default).init(); BEGIN LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText(Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END END A; CONST Nthreads=10000; BEGIN FOR i := 1 TO Nthreads DO Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush(Stdio.stdout); EVAL Thread.Fork(NEW(Cl)) END; LOOP WITH c = Rd.GetChar(Stdio.stdin) DO IF c = 'q' THEN EXIT END END END END Main. > >Olaf >-- >Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany >phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 >http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Mon Jul 16 08:27:36 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 15 Jul 2007 23:27:36 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Sun, 15 Jul 2007 23:41:31 EDT." Message-ID: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Mon Jul 16 14:42:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:42:43 -0400 Subject: [M3devel] strange errors... In-Reply-To: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> References: <200707160351.l6G3pX3M001871@camembert.async.caltech.edu> Message-ID: <4612CAB0-02E4-4D53-AF6F-B05C1972296E@cs.purdue.edu> I'll need to run this in the debugger. Do your previous instructions for download and build still hold true? On Jul 15, 2007, at 11:51 PM, Mika Nystrom wrote: > Tony Hosking writes: > ... >>> >>> Line 113 in Main.m3 is: >>> >>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); >> >> Where does the variable 'wr' come from? It is this 'wr' that is >> failing the assert. It should not be gray, assuming that the GC was >> able to find it. Can I see your Main.m3? >> > > It fails exactly the same way with @M3paranoidgc. > > wr comes from FileWr.Open. The programmer has re-used wr for two > open FileWrs... I marked line 113, where it crashes: > > (* Copyright (c) 2000 California Institute of Technology *) > (* All rights reserved. See the file COPYRIGHT for a full > description. *) > (* $Id: Main.m3,v 1.3 2002/12/11 08:54:53 kp Exp $ *) > > MODULE Main; > IMPORT Debug; > IMPORT tokformBundle, Bundle; > IMPORT TokParams; > IMPORT TokSpec; > IMPORT FileWr, Wr, Thread, OSError; > IMPORT TextWr; > IMPORT TextSubs; > IMPORT TextList; > IMPORT Pathname; > IMPORT Fmt; > IMPORT FmtTable; > (* IMPORT Term; *) > <* FATAL Thread.Alerted, Wr.Failure *> > > VAR > Form := tokformBundle.Get(); > > PROCEDURE FormatTypes(t: TextList.T; tokName, kind: TEXT): TEXT = > VAR > wr := TextWr.New(); > cur := t; > subs: TextSubs.T; > BEGIN > WHILE cur # NIL DO > subs := NEW(TextSubs.T).init(); > subs.add("%type", cur.head); > subs.add("%tok", tokName); > Wr.PutText(wr, subs.apply(Bundle.Get(Form, kind))); > cur := cur.tail; > END; > RETURN TextWr.ToText(wr); > END FormatTypes; > > PROCEDURE FormatLegalConst(tok: TokSpec.T): TEXT = > VAR > dummy: TEXT; > fmt := NEW(FmtTable.T).init(); > BEGIN > FOR i := 1 TO tok.lastConstCode DO > IF tok.constTokensR.get(i, dummy) THEN > fmt.putInt(i); > END; > END; > RETURN fmt.toText(); > END FormatLegalConst; > > PROCEDURE FormatNamedConst(tok: TokSpec.T): TEXT = > VAR > cur := tok.tokens; > name: TEXT; > code: INTEGER; > wr := TextWr.New(); > BEGIN > WHILE cur # NIL DO > name := cur.head; > IF tok.constTokens.get(name, code) THEN > Wr.PutText(wr, " " & name & " = " & Fmt.Int(code) & ";\n"); > END; > cur := cur.tail; > END; > RETURN TextWr.ToText(wr); > END FormatNamedConst; > > PROCEDURE Subs(tok: TokSpec.T; name: TEXT): TextSubs.T = > VAR > subs := NEW(TextSubs.T).init(); > BEGIN > subs.add("\\\n", ""); > subs.add("%tok", name); > subs.add("%type", FormatTypes(tok.varTokens, name, > "tokform.type")); > subs.add("%case", FormatTypes(tok.varTokens, name, > "tokform.case")); > subs.add("%constSet", FormatLegalConst(tok)); > subs.add("%constName", FormatNamedConst(tok)); > subs.add("%lastConst", Fmt.Int(tok.lastConstCode)); > subs.add("%gen", "(* Generated by ktok *)"); > RETURN subs; > END Subs; > > > VAR > tp: TokParams.T; > tok: TokSpec.T; > subs: TextSubs.T; > wr: Wr.T; > BEGIN > Debug.S("WELCOME!"); > tp := TokParams.Get("tok", ".t", "Tok.i3", FALSE); > Debug.S("GOT TOKPARAMS!"); > tok := TokParams.ReadTokens(tp); > Debug.S("GOT TOKENS"); > subs := Subs(tok, tp.outBase); > Debug.S("GOT SUBS!"); > TRY > wr := FileWr.Open(tp.out); > EXCEPT OSError.E => > Debug.Error("Cannot open tok interface output file: " & tp.out); > END; > > Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.i3"))); > Wr.Close(wr); > > TRY > wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3")); > EXCEPT OSError.E => > Debug.Error("Cannot open tok implementation output file: " & > Pathname.ReplaceExt(tp.out, "m3")); > END; > Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); (* > line 113 *) > Wr.Close(wr); > END Main. > From hosking at cs.purdue.edu Mon Jul 16 14:47:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:47:08 -0400 Subject: [M3devel] User-level threading In-Reply-To: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> References: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Message-ID: <319398F1-B01D-4E75-BBDA-AD31D9E951D4@cs.purdue.edu> Mixed systems are difficult to get working properly (because of interactions between system and user scheduling), and usually result in more trouble than they are worth (witness discussions on this subject regarding Jikes RVM). The difficulties are particularly pronounced with preemptive scheduling where system thread switches can occur at any time. My inclination is to implement the user-level threading properly using setcontext, etc., instead of setjmp/ longjmp. I will probably get to this next on my list of tinkering tasks with CM3. Right now, I want to finish off my LONGINT implementation (grappling with the compiler as we speak) as well as the GC issue you reported. On Jul 16, 2007, at 12:50 AM, Mika Nystrom wrote: > Olaf Wagner writes: >> On Wed, Jul 04, 2007 at 04:12:47PM -0400, Tony Hosking wrote: >>> In looking at things again, I am more and more convinced that >>> ThreadPosix should be implemented against the standard API for >>> makecontext/getcontext/setcontext/swapcontext. Platforms that do >>> not >>> provide these will need to provide an equivalent implementation of >>> these routines, similar to what you suggest. Right now, I know >>> all of >>> SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary >>> support. >> >> I think a `standard' implementation using makecontext/getcontext/... >> would be the best. For those platforms that do not support that, >> we can still use a C or assembler implementation. >> >> I would strongly vote for keeping user-level threading, too. > > Wouldn't the ideal be to have a mixed system, where N user-level > threads > run inside M <= N, M \approx NCPUS Pthreads? > > Anyone who thinks user-level threads are unnecessary should try the > following program, which runs just fine under user-level threads > on FreeBSD, and locks up horrendously after running about 4% of the > way on Darwin/Pthreads... > > Mika > > MODULE Main; > IMPORT Thread; > IMPORT Rd, Stdio, Wr, Random, Fmt; > > TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; > > > PROCEDURE A(cl : Cl) : REFANY = > VAR rand := NEW(Random.Default).init(); > BEGIN > LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText > (Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END > END A; > > CONST Nthreads=10000; > BEGIN > FOR i := 1 TO Nthreads DO > Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush > (Stdio.stdout); > EVAL Thread.Fork(NEW(Cl)) > END; > > LOOP > WITH c = Rd.GetChar(Stdio.stdin) DO > IF c = 'q' THEN EXIT END > END > END > END Main. > >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 >> Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 >> 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >> Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 From hosking at cs.purdue.edu Mon Jul 16 14:51:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 08:51:06 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: On Jul 16, 2007, at 2:27 AM, Mika Nystrom wrote: > An update: > > I was able to get everything to build by using @M3noincremental. Yes, this makes sense, since the error is one that can only occur with incremental GC. > > I am still running into a few errors when trying to run things. > So far, most problems seem to be traceable back to a garbage > collection > problem. @M3noincremental helps, but doesn't solve all GC-related > issues. > > The errors I seem to be running into are... > > 1. Some kind of memory protection error when I am reading pickles > from files. Haven't looked at this in detail yet. Odd. Please fill me in. > 2. The assert when spawning threads in mentor, mentioned earlier. I've not seen this since the fix I made a few weeks ago. It was related to weak references. > 3. Various sinks of processor time when running multithreaded things. > > The program I sent earlier to illustrate the (in)efficiency of > threading was an attempt to isolate some of the issues under 3., but > that simple program didn't seem to tickle any bugs. Instead, I have > an Othello program that does. It uses Trestle, X, etc., and you can > get it (via the references on the Wikipedia m3 page, actually: it > was originally part of an assignment for a class I was teaching at > Caltech). Cool. Another bug to chase. > What happens is this... everything seems functionally correct, but > after a while, the program, for no apparent reason at all, starts > to take 100% of the CPU. I think there may be several bugs. I have > been able to get programs to slow down and threads to stop running. I'd appreciate any hints you can give. What platform? Possibly related to thread stopping/restarting. > To the description: my othello program opens up a VBT and calls a > Thread.Join. This puts it in ThreadPThread.InnerWait, and there > all seems OK. The running thread (or one of them) calls Trestle.Ping, > which calls Thread.Pause. For a few seconds all is OK, the mouse > pointer is tracked, repaints work, etc. But after a while, the > program goes haywire. What happens is that the program is still > functionally correct, as before, but it starts to eat 100% CPU. > Looking a little closer, Thread.Pause has died, or is at least badly > wounded. It simply doesn't yield the CPU. > > I changed ThreadPThread.Pause to the following: > > PROCEDURE Pause(n: LONGREAL) = > VAR > amount, remaining: Utime.struct_timespec; > self := Self(); > BEGIN > IF self = NIL THEN Die(ThisLine(), "Pause called from a non- > Modula-3 thread") END; > IF n <= 0.0d0 THEN RETURN END; > IF perfOn THEN PerfChanged(self.id, State.pausing) END; > ToNTime(n, amount); > <* ASSERT amount.tv_sec >= 0 *> > > RTIO.PutChar('f'); RTIO.Flush(); > LOOP > RTIO.PutChar('b'); RTIO.Flush(); > <* ASSERT amount.tv_sec >= 0 *> (* line 756 *) > RTIO.PutChar('a'); RTIO.Flush(); > WITH nr = Utime.nanosleep(amount, remaining) DO > IF nr = 0 THEN > RTIO.PutChar('!'); RTIO.Flush(); > EXIT > ELSE > RTIO.PutChar('.'); RTIO.Flush(); > VAR > as := amount.tv_sec; > an := amount.tv_nsec; > rs := remaining.tv_sec; > rn := remaining.tv_nsec; > BEGIN > amount := remaining; > END > END > END > END; > IF perfOn THEN PerfChanged(self.id, State.alive) END; > END Pause; > > Ironically, the change seems to make the program slightly > less susceptible to trouble, but it still happens. The end result of > running my program is not terribly helpful: > > Repaint! > .ba.b > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 756 > *** That doesn't mesh with the latest version of ThreadPThread.m3. Are you sure you are up to date? > > > Program exited with code 01. > (gdb) where > No stack. > > Note that line 756 is after the arguments to nanosleep have already > been checked. The tv_secs gets set to -1... and nanosleep returns > right away. But nanosleep declares its first argument as const *, > so it's not nanosleep itself that's clobbering it. > > XXX > XXX The problem goes away with @M3nogc. This problem does NOT > XXX go away with @M3noincremental! > XXX > > (And @M3paranoidgc doesn't seem to be any more paranoid than the > usual one.) > > Maybe this is a stupid question... why are Pause and AlertPause > implemented with different system calls? (Note that I had another > program that was exhibiting the same type of processor greed, and > changing all occurrences of Pause to AlertPause in that program > didn't seem to cure it.) > > I think mentor and Juno show the 100% CPU symptoms as well. Yes, > I just re-ran mentor and I got the same assertion failing. > > ---- > > One last issue: there is indeed one more problem. @M3nogc does > solve the cpu utilization and Utime problems. It does not, however, > solve the protection bug (#1 above). Something's up, because Network > Objects do work fine, but reading and writing certain things to > disk does not appear to work (and those pickles were written by the > same executable as the one that tried to read them). All these > programs work reliably under PM3 on both FreeBSD and Windows > 2000/cygwin (not that I am suggesting that they are bug free). > > Mika > > > Tony Hosking writes: >> >> On Jul 15, 2007, at 9:53 PM, Mika Nystrom wrote: >> >>> Hello there, >>> >>> I am now back to trying to get my system compiled under CM3. Not >>> to pick on CM3 or anything, but my old PM3s still have no trouble >>> with it! >> >> PS Old PM3s don't have the new compiler-driven incremental >> collection scheme, so you will hopefully gain fromm moving to CM3 so >> long as we can fix your problem. I should be able to diagnose this >> without too much trouble. Any chance you can run with the >> @M3paranoidgc flag passed to tok? >> >>> >>> I'm back to staring at the following: >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 2310 >>> *** >>> >>> Here's how I got it: I ran the "tok" program from my example on one >>> of the example files (not sure if this is part of the distributed >>> "caltech-parser" or not). The revision of RTCollector.m3 is 1.29. >>> >>> I spoke to the author of "tok" last week (who now programs in a >>> kind of bastardized C++ with Modula-3 keywords and a garbage >>> collector), and he said this program actually does very little work. >>> It's just an interface generator that makes interfaces to declare >>> a few constants. Why it seems to have so much trouble running is >>> a mystery to me. >>> >>> traceback: >>> >>> (gdb) where >>> #0 0x9004308c in kill () >>> #1 0x9009fb3c in abort () >>> #2 0x00096f48 in RTOS__Crash () at RTOS.m3:20 >>> #3 0x0005bcd8 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at >>> RTProcess.m3:65 >>> #4 0x0008e4d8 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at >>> RTError.m3:115 >>> #5 0x0008e084 in RTError__MsgS (M3_AJWxb1_file=0xc6420, >>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0xca418, >>> M3_Bd56fi_msgB=0xcbed8, M3_Bd56fi_msgC=0xca418) at RTError.m3:40 >>> #6 0x0008eb80 in RTException__Crash (M3_Cblw37_a=0xbfffee20, >>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0xcb580) at RTException.m3:79 >>> #7 0x0008e744 in RTException__DefaultBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:39 >>> #8 0x0008e60c in RTException__InvokeBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:25 >>> #9 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at >>> RTExFrame.m3:29 >>> #10 0x0008e838 in RTException__DefaultBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:47 >>> #11 0x0008e60c in RTException__InvokeBackstop >>> (M3_Cblw37_a=0xbfffee20, M3_AicXUJ_raises=0 '\0') at >>> RTException.m3:25 >>> #12 0x00095cfc in RTException__Raise (M3_Cblw37_act=0xbfffee20) at >>> RTExFrame.m3:29 >>> #13 0x00079738 in RTHooks__ReportFault (M3_AJWxb1_module=0xb3ec0, >>> M3_AcxOUs_info=73920) at RTHooks.m3:110 >>> #14 0x0006ff44 in _m3_fault (M3_AcxOUs_arg=73920) >>> #15 0x0006bcec in RTHooks__CheckStoreTraced >>> (M3_Af40ku_ref=0xb24368) at RTCollector.m3:2310 >>> #16 0x000700dc in ThreadPThread__InnerLockMutex >>> (M3_AYIbX3_m=0xb24368, M3_BXP32l_self=0xb244b0) at >>> ThreadPThread.m3:126 >>> #17 0x000704d0 in ThreadPThread__LockMutex (M3_AYIbX3_m=0xb24368) >>> at ThreadPThread.m3:153 >>> #18 0x00019abc in Wr__PutText (M3_BxxOH1_wr=0xb24368, >>> M3_Bd56fi_t=0xb403d4) at Wr.m3:93 >>> #19 0x00003e94 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113 >>> #20 0x0005b15c in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at >>> RTLinker.m3:399 >>> #21 0x00059f20 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at >>> RTLinker.m3:113 >>> #22 0x0005a01c in RTLinker__AddUnit (M3_DjPxE5_b=0x3520) at >>> RTLinker.m3:122 >>> #23 0x00001ecc in main (argc=4, argv=0xbffffb30, envp=0xbffffb44) >>> at _m3main.mc:4 >>> (gdb) >>> >>> Line 113 in Main.m3 is: >>> >>> Wr.PutText(wr, subs.apply(Bundle.Get(Form, "tokform.m3"))); >>> >>> (Bundle is made by m3bundle) >>> >>> OS: >>> Darwin lapdog.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> This is a CM3 checkout from yesterday, built cleanly according to >>> your instructions (starting with an absolutely clean system and >>> bootstrapped using binary version 5.4.0). I managed to screw it >>> up at one point but I ran do-cm3-std realclean and do-cm3-core >>> realclean several times. >>> >>> But isn't this the bug you already fixed? I just don't see how I >>> could possibly be getting an old RTCollector.m3 file in my system. >>> I cleaned it obsessively while I was building it. >>> >>> I am using the cfg file you sent me, too. (I copied it in, in place >>> of the 5.4.0 default cfg.) You can see I am using pthreads. >>> >>> @M3noincremental and @M3nogc work, as usual. >>> >>> ---------- >>> >>> I saw another problem. I was running mentor, the packet routing >>> animation, and hit an assertion in ThreadPThread.m3. >>> >>> >>> [lapdog:~] mika% mentor >>> >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 673 >>> *** >>> >>> Abort >>> >>> WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*> >>> END; >>> WITH r = Upthread.attr_init(attr) DO <*ASSERT r=0*> END; >>> WITH r = Upthread.attr_getstacksize(attr, bytes) DO >>> <*ASSERT r=0*> END; >>> bytes := MAX(bytes, size * ADRSIZE(Word.T)); >>> WITH r = Upthread.attr_setstacksize(attr, bytes) DO >>> <*ASSERT r=0*> END; (* line 673 *) >>> WITH r = Upthread.create(act.handle, attr, ThreadBase, >>> act) DO >>> <*ASSERT r=0*> >>> END; >>> act.next := allThreads; >>> act.prev := allThreads.prev; >>> act.size := size; >>> allThreads.prev.next := act; >>> allThreads.prev := act; >>> WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*> >>> END; >>> END; >>> >>> Is it trying to make too many threads? Is there a practical limit >>> on the number of threads under pthreads? (The code I am eventually >>> going to want to build will want to make hundreds and possibly >>> thousands of concurrently executing threads, which I don't think >>> is a problem with ThreadPosix, and I'll be pretty disappointed if >>> that turns out to be a problem with pthreads...well I suppose I can >>> always go back to user-level threads.) >>> >>> Mika >>> >>> >>> Tony Hosking writes: >>>> Sigh, this is a knock-on bug that manifests as a result of the >>>> supposed "fix" I made in response to your previous post. As it >>>> turns >>>> out, the user-level threads code has some badness built in with >>>> respect to incremental GC. I need to rework the user-level >>>> threading >>>> code to totally eliminate use of traced references in the code for >>>> ProcessStacks. The ring of threads needs to be maintained in an >>>> untraced data structure for the newer GC code to work properly. >>>> This >>>> is something that is very carefully done in the pthreads-based >>>> system- >>>> level threading that is used on all the platforms I typically >>>> maintain locally (SOLgnu/SOLsun, LINUXLIBC6, I386_DARWIN, >>>> PPC_DARWIN), so I haven't seen this problem so extensively. You >>>> are >>>> correct that running without incremental collection (using >>>> @M3noincremental) will avoid the problem until I am able to come up >>>> with a fix. >>>> >>>> On Jul 2, 2007, at 6:35 AM, Mika Nystrom wrote: >>>> >>>>> Ok, things are certainly better on FreeBSD/i386 now. I just spent >>>>> a few minutes playing a newly compiled tetris. >>>>> >>>>> However, I still get that very first error I wrote about: >>>>> >>>>> /home/mika/u/parserlib/ktok/FreeBSD4/tok ../src/Lang.t -o >>>>> LangTok.i3 >>>>> WELCOME! >>>>> GOT TOKPARAMS! >>>>> GOT TOKENS >>>>> GOT SUBS! >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** <*ASSERT*> failed. >>>>> *** file "../src/runtime/common/RTCollector.m3", line 2310 >>>>> *** >>>>> >>>>> What I did was... I wasn't sure exactly what state my CM3 was in, >>>>> as usual, so I deleted all of /usr/local/cm3, plus my repository >>>>> checkout, checked it out from scratch, and followed your bootstrap >>>>> instructions of June 24 to the letter, except that where you said >>>>> to do "do-cm3-std.sh realclean" I did "do-cm3-core.sh realclean" >>>>> and then "do-cm3-std.sh realclean", built the stage 1 and stage 2, >>>>> installed the new compiler. No problems until trying to run >>>>> this code, which is part of our local version of the "caltech- >>>>> parser"... >>>>> Here we go: >>>>> >>>>> >>>>> Program received signal SIGABRT, Aborted. >>>>> 0x68b5e0c7 in kill () from /lib/libc.so.5 >>>>> (gdb) where >>>>> #0 0x68b5e0c7 in kill () from /lib/libc.so.5 >>>>> #1 0x68b5312e in raise () from /lib/libc.so.5 >>>>> #2 0x68bc6cef in abort () from /lib/libc.so.5 >>>>> #3 0x682bc7f2 in RTOS__Crash () at RTOS.m3:20 >>>>> #4 0x682b3b66 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at >>>>> RTProcess.m3:65 >>>>> #5 0x682b1e30 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at >>>>> RTError.m3:115 >>>>> #6 0x682b1b71 in RTError__MsgS (M3_AJWxb1_file=0x682dd4c8, >>>>> M3_AcxOUs_line=2310, M3_Bd56fi_msgA=0x682df048, >>>>> M3_Bd56fi_msgB=0x682d9630, M3_Bd56fi_msgC=0x682df048) at >>>>> RTError.m3:40 >>>>> #7 0x682b21f4 in RTException__Crash (M3_Cblw37_a=0xbfbfe0b8, >>>>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0x682d94e0) at >>>>> RTException.m3:79 >>>>> #8 0x682b1f58 in RTException__DefaultBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:39 >>>>> #9 0x682b1ebc in RTException__InvokeBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:25 >>>>> #10 0x682bdc37 in RTException__Raise (M3_Cblw37_act=0xbfbfe0b8) at >>>>> RTExFrame.m3:29 >>>>> #11 0x682b1ff8 in RTException__DefaultBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:47 >>>>> #12 0x682b1ebc in RTException__InvokeBackstop >>>>> (M3_Cblw37_a=0xbfbfe0b8, M3_AicXUJ_raises=0 '\0') at >>>>> RTException.m3:25 >>>>> #13 0x682bdc37 in RTException__Raise (M3_Cblw37_act=0xbfbfe0b8) at >>>>> RTExFrame.m3:29 >>>>> #14 0x6829da9e in RTHooks__ReportFault >>>>> (M3_AJWxb1_module=0x682dd640, M3_AcxOUs_info=73920) at >>>>> RTHooks.m3:110 >>>>> #15 0x682afc48 in _m3_fault (M3_AcxOUs_arg=73920) from /usr/local/ >>>>> cm3/pkg/m3core/FreeBSD4/libm3core.so.5 >>>>> #16 0x682ad065 in RTHooks__CheckStoreTraced >>>>> (M3_Af40ku_ref=0x68c2b104) at RTCollector.m3:2310 >>>>> #17 0x682bfba2 in ThreadPosix__LockMutex (M3_AYIbX3_m=0x68c2b104) >>>>> at ThreadPosix.m3:416 >>>>> #18 0x681ab817 in Wr__PutText (M3_BxxOH1_wr=0x68c2b104, >>>>> M3_Bd56fi_t=0x68c05608) at Wr.m3:93 >>>>> #19 0x0804a445 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113 >>>>> #20 0x682b120a in RTLinker__RunMainBody (M3_DjPxE3_m=0x804cae0) at >>>>> RTLinker.m3:399 >>>>> #21 0x682b0735 in RTLinker__AddUnitI (M3_DjPxE3_m=0x804cae0) at >>>>> RTLinker.m3:113 >>>>> #22 0x682b07bc in RTLinker__AddUnit (M3_DjPxE5_b=0x8049e50) at >>>>> RTLinker.m3:122 >>>>> #23 0x080491f5 in main (argc=4, argv=0xbfbfe40c, envp=0xbfbfe420) >>>>> at _m3main.mc:4 >>>>> (gdb) >>>>> >>>>> 2302 PROCEDURE CheckStoreTraced (ref: REFANY) = >>>>> 2303 VAR p := Word.RightShift (LOOPHOLE(ref, Word.T), >>>>> LogBytesPerPage); >>>>> 2304 BEGIN >>>>> 2305 RTOS.LockHeap (); >>>>> 2306 INC(checkStoreTraced); >>>>> 2307 >>>>> 2308 WITH h = HeaderOf (LOOPHOLE(ref, RefReferent)) DO >>>>> 2309 <*ASSERT h.typecode # RT0.TextLitTypecode*> >>>>> 2310 <*ASSERT NOT h.gray*> >>>>> 2311 >>>>> 2312 IF h.dirty THEN >>>>> 2313 <*ASSERT NOT desc[p - p0].clean*> >>>>> 2314 ELSE >>>>> 2315 h.dirty := TRUE; >>>>> 2316 IF desc[p - p0].clean THEN >>>>> 2317 desc[p - p0].clean := FALSE; >>>>> 2318 IF perfOn THEN PerfChange(p, PageCount(p)); END; >>>>> 2319 END; >>>>> 2320 END; >>>>> 2321 END; >>>>> 2322 >>>>> 2323 RTOS.UnlockHeap(); >>>>> 2324 RETURN; >>>>> 2325 END CheckStoreTraced; >>>>> >>>>> I believe this is the same as the first bug I ran across. The >>>>> program >>>>> (ktok) does appear to work fine with @M3nogc. >>>>> >>>>> Further information: I am also "able" to get mentor and Juno to >>>>> crash on this line 2310. I checked the bootstrapping process by >>>>> building a third-stage bootstrapped compiler, and it was byte-for- >>>>> byte >>>>> identical to the second-stage bootstrap. Finally, I am still a >>>>> bit >>>>> worried about libraries (maybe across the different booting >>>>> stages) >>>>> getting polluted: I am able to run Juno, mentor, etc., except for >>>>> the garbage-collection problem, but my own Trestle applications >>>>> crash somewhere in the (C) X libraries, even though they have >>>>> worked >>>>> fine on several other versions of Modula-3. (Most likely, of >>>>> course, >>>>> it's some sort of bug of mine... generally I am not in the >>>>> habit of >>>>> blaming the libraries or compiler, but you never know!) >>>>> >>>>> The line-2310 crashes also seem to go away with @M3noincremental, >>>>> by the >>>>> way. >>>>> >>>>> >>>>> >>>>> Mika >>>>> >>>>> Tony Hosking writes: >>>>>> I've just checked in a fix to ThreadPosix.m3 that eliminates your >>>>>> problem with user-level threads. I have tested this on >>>>>> I386_DARWIN >>>>>> and it appears to be working just fine now. Please try again >>>>>> with >>>>>> the updated ThreadPosix.m3. >>>>>> >>>>>> On Jun 25, 2007, at 3:05 PM, Mika Nystrom wrote: >>>>>> >>>>>>> Indeed, -g was one of the culprits. I changed it to -gstabs+ >>>>>>> and >>>>>>> got a bit further... (please scroll down to STEP 2, sorry) >>>>>>> >>>>>>> Tony Hosking writes: >>>>>>>> Sounds like we really need some work done in this area. I very >>>>>>>> rarely use the build scripts, since I bootstrap manually >>>>>>>> from old >>>>>>>> compilers to new compilers rather than use the scripts. I >>>>>>>> suggest >>>>>>>> the following approach, which I hope you will try, and then >>>>>>>> report >>>>>>>> back on. >>>>>>>> >>>>>>>> Install the bootstrap compiler as you did originally: >>>>>>>> >>>>>>>>> rm -rf /usr/local/cm3/* >>>>>>>>> >>>>>>>>> cd ~/cm3-cvs >>>>>>>>> mkdir boot >>>>>>>>> cd boot >>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz >>>>>>>>> ./cminstall >>>>>>>> >>>>>>>> Now you will have some kind of cm3 installed, presumably in / >>>>>>>> usr/ >>>>>>>> local/cm3/bin/cm3. >>>>>>>> >>>>>>>> Make sure you have a fresh CVS checkout in directory cm3 (let's >>>>>>>> assume this is in your home directory ~/cm3). Also, make sure >>>>>>>> you >>>>>>>> have an up-to-date version of the CM3 backend compiler cm3cg >>>>>>>> installed by executing the following: >>>>>>>> >>>>>>>> STEP 0: >>>>>>>> >>>>>>>> export CM3=/usr/local/cm3/bin/cm3 >>>>>>>> cd ~/cm3/m3-sys/m3cc >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> >>>>>>>> You can skip this last step if you know your backend compiler >>>>>>>> is up >>>>>>>> to date. >>>>>>>> >>>>>>>> Now, let's build the new compiler from scratch (this is the >>>>>>>> sequence >>>>>>>> I use regularly to test changes to the run-time system >>>>>>>> whenever I >>>>>>>> make them): >>>>>>>> >>>>>>>> STEP 1: >>>>>>>> >>>>>>>> cd ~/cm3/m3-libs/m3core >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-libs/libm3 >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3middle >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3linker >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3front >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/m3quake >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> cd ~/cm3/m3-sys/cm3 >>>>>>>> $CM3 >>>>>>>> $CM3 -ship >>>>>>>> >>>>>>>> At this point you should have a bootstrapped version of cm3 >>>>>>>> installed >>>>>>>> in the directory /usr/local/cm3/pkg/cm3/TARGET/cm3 (where >>>>>>>> TARGET is >>>>>>>> the CM3 target platform you are building on -- e.g., >>>>>>>> LINUXLIBC6, >>>>>>>> PPC_DARWIN, ...). Note that this did not overwrite your >>>>>>>> original >>>>>>>> installed compiler in /usr/local/cm3/bin/cm3. We >>>>>>>> are now going to test the new compiler, which was built using >>>>>>>> the old >>>>>>>> compiler, by bootstrapping it one more time. >>>>>>>> >>>>>>>> From here on out, please replace TARGET with your target >>>>>>>> platform as >>>>>>>> appropriate. >>>>>>>> >>>>>>>> STEP 2: >>>>>>>> >>>>>>>> export CM3=/usr/local/cm3/pkg/cm3/TARGET/cm3 >>>>>>>> cd ~/cm3/scripts >>>>>>>> ./do-cm3-std.sh realclean >>>>>>>> REPEAT STEP 1 to rebuild the libraries and the compiler >>>>>>>> using the >>>>>>>> STEP 1 bootstrap compiler. >>>>>>>> >>>>>>>> Now you have a STEP 2 bootstrap compiler installed in /usr/ >>>>>>>> local/ >>>>>>>> cm3/ >>>>>>>> pkg/cm3/TARGET/cm3. Let's assume the new compiler now works >>>>>>>> properly >>>>>>>> since it successfully bootstrapped itself, but to be sure we >>>>>>>> can >>>>>>>> now >>>>>>>> use it to rebuild the world: >>>>>>> >>>>>>> Ok, I got this far. I built the step 1 (m3core...cm3), set my >>>>>>> compiler to the newly-built compiler, and rebuilt >>>>>>> (m3core...cm3). >>>>>>> No errors anywhere, beautiful. >>>>>>> >>>>>>>> >>>>>>>> cd ~/cm3/scripts >>>>>>>> ./do-cm3-std.sh realclean >>>>>>>> ./do-cm3-std.sh buildship >>>>>>> >>>>>>> Here's where it dies: >>>>>>> >>>>>>> ./do-cm3-std.sh buildship >>>>>>> CM3C = >>>>>>> /big/home2/mika/2/cm3-cvs/fresh/cm3/scripts/pkgmap.sh -c "/usr/ >>>>>>> local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/home2/ >>>>>>> mika/2/ >>>>>>> cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 - >>>>>>> ship - >>>>>>> DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' " m3core libm3 >>>>>>> patternmatching m3middle m3quake m3scanner m3tools m3cgcat >>>>>>> m3cggen >>>>>>> m3gdb m3bundle arithmetic bitvector digraph parseparams >>>>>>> realgeometry set slisp sortedtableextras table-list tempfiles >>>>>>> tcp >>>>>>> udp libsio libbuf debug listfuncs embutils m3tk-misc http binIO >>>>>>> commandrw m3tk mtex m3totex m3tohtml m3scan m3markup m3browser >>>>>>> cmpdir cmpfp dirfp uniq netobj netobjd stubgen events rdwr >>>>>>> sharedobj sharedobjgen odbc postgres95 db smalldb stable >>>>>>> stablegen >>>>>>> X11R4 ui PEX vbtkit cmvbt jvideo videovbt web formsvbtpixmaps >>>>>>> formsvbt formsview formsedit codeview mg mgkit opengl anim3D >>>>>>> zeus >>>>>>> m3zume synloc synex metasyn obliqrt obliqparse obliqprint obliq >>>>>>> obliqlibemb obliqlibm3 obliqlibui obliqlibanim obliqsrvstd >>>>>>> obliqsrvui obliqbinmin obliqbinstd obliqbin! >>>>>>> ui obliqbinanim visualobliq vocgi voquery vorun webvbt >>>>>>> recordheap >>>>>>> rehearsecode replayheap showheap shownew showthread pkl-fonts >>>>>>> juno- >>>>>>> machine juno-compiler juno-app cube calculator fisheye mentor >>>>>>> === package /big/home2/mika/2/cm3-cvs/fresh/cm3/m3-libs/ >>>>>>> m3core === >>>>>>> +++ /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 -build -DROOT='/big/ >>>>>>> home2/ >>>>>>> mika/2/cm3-cvs/fresh/cm3' && /usr/local/cm3/pkg/cm3/FreeBSD4/ >>>>>>> cm3 - >>>>>>> ship -DROOT='/big/home2/mika/2/cm3-cvs/fresh/cm3' +++ >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>> >>>>>>> Abort trap >>>>>>> *** execution of failed *** >>>>>>> >>>>>>> This time it appears to be cm3 itself that's crashing: >>>>>>> >>>>>>> (310)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>$CM3 -keep - >>>>>>> commands >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> >>>>>>> >>>>>>> *** >>>>>>> *** runtime error: >>>>>>> *** <*ASSERT*> failed. >>>>>>> *** file "../src/runtime/common/RTCollector.m3", line 690 >>>>>>> *** >>>>>>> >>>>>>> Abort >>>>>>> >>>>>>> What follows is what m3gdb has to say about this. I take it >>>>>>> that >>>>>>> the last error message comes from my -gstabs+ option. m3gdb >>>>>>> doesn't >>>>>>> like this new binary: it can't print variables and sometimes >>>>>>> crashes >>>>>>> trying. Would I have better luck with "-gstabs", do you >>>>>>> think? Or >>>>>>> do I just need to fix the compile process and install a new >>>>>>> m3gdb? >>>>>>> (I take it there is a newer one: mine is very old. But I >>>>>>> remember >>>>>>> that m3gdb doesn't always work that well...) >>>>>>> >>>>>>> Mika >>>>>>> >>>>>>> #1 16_81a619d in __raise () >>>>>>> #2 16_81a3b8f in abort () >>>>>>> #3 16_8178d16 in RTOS.Crash () at RTOS.m3:20 >>>>>>> #4 16_8171fd2 in RTProcess.Crash (msg=NIL) at RTProcess.m3:65 >>>>>>> #5 16_8170428 in RTError.EndError (crash=TRUE) at >>>>>>> RTError.m3:115 >>>>>>> #6 16_8170169 in RTError.MsgS (file=16_820a508, line=690, >>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at >>>>>>> RTError.m3:40 >>>>>>> #7 16_81707ec in RTException.Crash (a=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79 >>>>>>> #8 16_8170550 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39 >>>>>>> #9 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #10 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #11 16_81705f0 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47 >>>>>>> #12 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #13 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #14 16_8160bba in RTHooks.ReportFault (module=16_820a680, >>>>>>> info=22080) at RTHooks.m3:110 >>>>>>> #15 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0 >>>>>>> #16 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> #17 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3300) at >>>>>>> RTCollector.m3:2296 >>>>>>> #18 16_814400c in Stdio.ShutDown () at Stdio.m3:43 >>>>>>> #19 16_8171f51 in RTProcess.InvokeExitors () at RTProcess.m3:40 >>>>>>> #20 16_8171fc5 in RTProcess.Crash (msg=NIL) at RTProcess.m3:61 >>>>>>> #21 16_8170428 in RTError.EndError (crash=TRUE) at >>>>>>> RTError.m3:115 >>>>>>> #22 16_8170169 in RTError.MsgS (file=16_820a508, line=690, >>>>>>> msgA=16_820bfe8, msgB=16_8208170, msgC=16_820bfe8) at >>>>>>> RTError.m3:40 >>>>>>> #23 16_81707ec in RTException.Crash (a=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END, raises=FALSE, rte=16_8208020) at RTException.m3:79 >>>>>>> #24 16_8170550 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:39 >>>>>>> #25 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #26 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #27 16_81705f0 in RTException.DefaultBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:47 >>>>>>> #28 16_81704b4 in RTException.InvokeBackstop (a=RECORD >>>>>>> exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; >>>>>>> un_arg = NIL; END, raises=FALSE) at RTException.m3:25 >>>>>>> #29 16_8179ca7 in RTException.Raise (act=RECORD exception = >>>>>>> 16_8208020; arg = 16_c; module = 16_820a680; line = 690; pc = >>>>>>> NIL; >>>>>>> info0 = NIL; info1 = NIL; un_except = 16_8208020; un_arg = NIL; >>>>>>> END) at RTExFrame.m3:29 >>>>>>> #30 16_8160bba in RTHooks.ReportFault (module=16_820a680, >>>>>>> info=22080) at RTHooks.m3:110 >>>>>>> #31 16_816e251 in _m3_fault (arg=22080) at RTCollector.m3:0 >>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3004) at >>>>>>> RTCollector.m3:2296 >>>>>>> #34 16_817c41e in ThreadF.ProcessStacks (p=16_816415e) at >>>>>>> ThreadPosix.m3:522 >>>>>>> #35 16_8165213 in RTCollector.CollectSomeInStateZero () at >>>>>>> RTCollector.m3:845 >>>>>>> #36 16_8164d2c in RTCollector.CollectSome () at >>>>>>> RTCollector.m3:741 >>>>>>> #37 16_816487b in RTCollector.CollectEnough () at >>>>>>> RTCollector.m3:659 >>>>>>> #38 16_81673cd in RTHeapRep.AllocTraced (def=16_81f8f38, >>>>>>> dataSize=8200, dataAlignment=4, initProc=16_bfbfe0f4, >>>>>>> pool=RECORD >>>>>>> desc = RECORD space = Current; generation = Younger; pure = >>>>>>> FALSE; >>>>>>> note = Allocated; gray = FALSE; clean = FALSE; continued = >>>>>>> FALSE; link = 0; END; notAfter = {Copied}; page = 0; stack = 0; >>>>>>> next = NIL; limit = NIL; busy = FALSE; END) >>>>>>> at RTCollector.m3:1417 >>>>>>> #39 16_816218e in RTAllocator.GetOpenArray (def=16_81f8f38, s= >>>>>>> [2048]) at RTAllocator.m3:308 >>>>>>> #40 16_8161737 in RTHooks.AllocateOpenArray (defn=16_81f8f38, s= >>>>>>> [2048]) at RTAllocator.m3:156 >>>>>>> #41 16_8129d56 in M3ID_M3 (mode=1) at M3ID.m3:40 >>>>>>> #42 16_816f802 in RTLinker.RunMainBody (m=16_81f8cc0) at >>>>>>> RTLinker.m3:399 >>>>>>> #43 16_816f6ca in RTLinker.RunMainBody (m=16_81c0880) at >>>>>>> RTLinker.m3:379 >>>>>>> #44 16_816f6ca in RTLinker.RunMainBody (m=16_81c06a0) at >>>>>>> RTLinker.m3:379 >>>>>>> #45 16_816f6ca in RTLinker.RunMainBody (m=16_81bc920) at >>>>>>> RTLinker.m3:379 >>>>>>> #46 16_816ed2d in RTLinker.AddUnitI (m=16_81bc920) at >>>>>>> RTLinker.m3:113 >>>>>>> #47 16_816edb4 in RTLinker.AddUnit (b=16_8065527) at >>>>>>> RTLinker.m3:122 >>>>>>> module "_m3main": missing debug info for global data >>>>>>> >>>>>>> (gdb) up 32 >>>>>>> #32 16_81649b7 in RTCollector.CollectorOn () at >>>>>>> RTCollector.m3:690 >>>>>>> RTCollector.m3:690: No such file or directory. >>>>>>> (gdb) >>>>>>> Suspended >>>>>>> (360)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>find ../.. -name >>>>>>> RTCollector.m3 >>>>>>> ../../m3-libs/m3core/src/runtime/common/RTCollector.m3 >>>>>>> (361)rover:~/cm3-cvs/fresh/cm3/m3-libs/m3core>fg >>>>>>> m3gdb /usr/local/cm3/pkg/cm3/FreeBSD4/cm3 >>>>>>> (gdb) dir ../../m3-libs/m3core/src/runtime/common/ >>>>>>> Source directories searched: /big/home2/mika/2/cm3-cvs/fresh/ >>>>>>> cm3/m3- >>>>>>> libs/m3core/../../m3-libs/m3core/src/runtime/common:$cdir:$cwd >>>>>>> (gdb) list >>>>>>> 685 VAR timeOnEntry, timeOnExit: Time.T; (* time of >>>>>>> collector entry/exit *) >>>>>>> 686 >>>>>>> 687 PROCEDURE CollectorOn () = >>>>>>> 688 (* LL >= RTOS.LockHeap *) >>>>>>> 689 BEGIN >>>>>>> 690 <* ASSERT NOT collectorOn *> >>>>>>> 691 collectorOn := TRUE; >>>>>>> 692 >>>>>>> 693 IF incremental AND NOT RTLinker.incremental >>>>>>> 694 OR generational AND NOT RTLinker.generational THEN >>>>>>> (gdb) print collectorOn >>>>>>> can't find identifier: collectorOn >>>>>>> (gdb) up >>>>>>> #33 16_816b595 in RTHooks.CheckLoadTracedRef >>>>>>> (ref=16_681b3004) at >>>>>>> RTCollector.m3:2296 >>>>>>> 2296 CollectorOn(); >>>>>>> (gdb) print collectorOn >>>>>>> can't find identifier: collectorOn >>>>>>> (gdb) print ref >>>>>>> Segmentation fault >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Assuming this succeeded then we can be pretty sure /usr/local/ >>>>>>>> cm3/ >>>>>>>> pkg/ >>>>>>>> cm3/TARGET/cm3 is good, so we can make it our default >>>>>>>> compiler by >>>>>>>> replacing the original /usr/local/cm3/bin/cm3: >>>>>>>> >>>>>>>> cp $CM3 /usr/local/cm3/bin/cm3 >>>>>>>> >>>>>>>> On Jun 23, 2007, at 2:38 PM, Mika Nystrom wrote: >>>>>>>> >>>>>>>>> Ok, I'm sorry if I seem a bit dimwitted in the morning like >>>>>>>>> this, >>>>>>>>> but how exactly does one get started? I wish there were a >>>>>>>>> file >>>>>>>>> called >>>>>>>>> "GETTING_STARTED" or something like that in scripts... >>>>>>>>> >>>>>>>>> My Mac is very slow so I switched to my FreeBSD/i386 system >>>>>>>>> (which has >>>>>>>>> PM3 happily installed on it) and tried to install CM3 from >>>>>>>>> scratch. >>>>>>>>> Here are the exact commands I typed. >>>>>>>>> >>>>>>>>> >>>>>>>>> rm -rf /usr/local/cm3/* >>>>>>>>> >>>>>>>>> cd ~/cm3-cvs >>>>>>>>> mkdir boot >>>>>>>>> cd boot >>>>>>>>> tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz >>>>>>>>> ./cminstall >>>>>>>>> >>>>>>>>> # now I seem to have some kind of cm3 installed, /usr/local/ >>>>>>>>> cm3/ >>>>>>>>> bin/ >>>>>>>>> cm3 >>>>>>>>> >>>>>>>>> cd cm3 # location of my CM3 checkout >>>>>>>>> cvs update -d . >>>>>>>>> >>>>>>>>> cd scripts >>>>>>>>> ./boot-cm3-with-m3.sh realclean >>>>>>>>> ./do-cm3-std.sh realclean >>>>>>>>> >>>>>>>>> ./upgrade.sh # fails here, libm3 not >>>>>>>>> compiled >>>>>>>>> ./boot-cm3-with-m3.sh build # builds cm3, but fails on >>>>>>>>> cminstall, patternmatching not built >>>>>>>>> >>>>>>>>> ./do-cm3-std.sh build # OK >>>>>>>>> ./do-cm3-std.sh buildship # OK >>>>>>>>> >>>>>>>>> ./boot-cm3-with-m3.sh realclean # start over >>>>>>>>> ./boot-cm3-with-m3.sh build # OK >>>>>>>>> ./boot-cm3-with-m3.sh buildship # OK >>>>>>>>> >>>>>>>>> ./do-cm3-std.sh realclean # OK >>>>>>>>> ./do-cm3-std.sh build # dies miserably... maybe >>>>>>>>> the >>>>>>>>> compiler can't handle the new libraries? >>>>>>>>> >>>>>>>>> ./install-cm3-compiler.sh upgrade # OK, new cm3 binary >>>>>>>>> installed >>>>>>>>> >>>>>>>>> After all that, "game over." I have a cm3 that segfaults. >>>>>>>>> >>>>>>>>> Text.i3: In function 'Text_I3': >>>>>>>>> Text.i3:81: internal compiler error: Segmentation fault >>>>>>>>> Please submit a full bug report, >>>>>>>>> with preprocessed source if appropriate. >>>>>>>>> See 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? From hosking at cs.purdue.edu Mon Jul 16 18:32:25 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:32:25 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: Again, please confirm that you are using the CVS head. 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 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? From hosking at cs.purdue.edu Mon Jul 16 18:47:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:47:06 -0400 Subject: [M3devel] User-level threading In-Reply-To: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> References: <200707160450.l6G4oqRg002812@camembert.async.caltech.edu> Message-ID: <4E226F4D-9281-4FBA-9306-591A39ED64CC@cs.purdue.edu> This runs fine for me on Darwin pthreads up until it fails trying to create a new pthread after 6982 threads: the call to pthread_create returns an error code. I am assuming the error is due to hitting some system limit. On Jul 16, 2007, at 12:50 AM, Mika Nystrom wrote: > MODULE Main; > IMPORT Thread; > IMPORT Rd, Stdio, Wr, Random, Fmt; > > TYPE Cl = Thread.Closure OBJECT OVERRIDES apply := A END; > > > PROCEDURE A(cl : Cl) : REFANY = > VAR rand := NEW(Random.Default).init(); > BEGIN > LOOP Thread.Pause(rand.longreal(1.05d0,1.15d0)); Wr.PutText > (Stdio.stdout,"."); Wr.Flush(Stdio.stdout) END > END A; > > CONST Nthreads=10000; > BEGIN > FOR i := 1 TO Nthreads DO > Wr.PutText(Stdio.stdout, Fmt.Int(i) & "...\n"); Wr.Flush > (Stdio.stdout); > EVAL Thread.Fork(NEW(Cl)) > END; > > LOOP > WITH c = Rd.GetChar(Stdio.stdin) DO > IF c = 'q' THEN EXIT END > END > END > END Main. From hosking at cs.purdue.edu Mon Jul 16 18:57:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 12:57:28 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> References: <200707160627.l6G6RanS004381@camembert.async.caltech.edu> Message-ID: 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 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? From mika at async.caltech.edu Mon Jul 16 21:33:53 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 16 Jul 2007 12:33:53 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Mon, 16 Jul 2007 12:57:28 EDT." Message-ID: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> 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 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? From hosking at cs.purdue.edu Tue Jul 17 00:53:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 16 Jul 2007 18:53:49 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> References: <200707161933.l6GJXrIp019389@camembert.async.caltech.edu> Message-ID: <31544177-4CC1-42C6-8306-DF3AD5BC5775@cs.purdue.edu> 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 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? From mika at async.caltech.edu Tue Jul 17 09:31:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 17 Jul 2007 00:31:44 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Mon, 16 Jul 2007 18:53:49 EDT." <31544177-4CC1-42C6-8306-DF3AD5BC5775@cs.purdue.edu> Message-ID: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> 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=, M3_CVvbAZ_session=0x1f93290, M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=) 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=, M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Tue Jul 17 16:34:53 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 17 Jul 2007 10:34:53 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> References: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> Message-ID: Good. I'll try to digest your report more deeply before getting back. Generally, try running with @M3noincremental @M3nogenerational to run with simple GC but without the bells and whistles. You can add @M3paranoidgc to be particularly careful. That way, at least we know that you are getting the benefit of GC without major complications. 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=, M3_CVvbAZ_session=0x1f93290, > M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', > M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid= 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=, > M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Thu Jul 19 05:53:38 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 18 Jul 2007 23:53:38 -0400 Subject: [M3devel] LONGINT Message-ID: I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. From wagner at elegosoft.com Thu Jul 19 08:23:50 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 19 Jul 2007 08:23:50 +0200 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <20070719062350.GA12517@elegosoft.com> On Wed, Jul 18, 2007 at 11:53:38PM -0400, Tony Hosking wrote: > I've successfully bootstrapped a CM3 compiler that supports LONGINT > as a 64-bit integer type (equivalent to "long long" in C) in addition > to INTEGER (same as "long" in C). This will be useful for > simplifying interfaces to C library routines that expect to be able > to treat 64-bit integers such as "off_t" for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type > (I'm not sure this would ever be a good idea) so it cannot be used to > index arrays, define enumerations etc., though the simple operations > ABS, MAX, MIN, addition, comparisons, MOD, multiplication, > subtraction, assignment, are all supported. This includes changes to > m3core (with support for Long.T similar to Word.T, plus RTTipe and > RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, > m3front, and the gcc-based compiler backend. There is still work > that needs to be done to support and test all the other M3 tools such > as network objects, etc., with support and testing needed in m3tk for > the new type, as well as in other tools like m3browser. This sounds great! As this topic had been discussed several times, and nothing ever came of it, I'd rather thought that it wouldn't be different this time. So at last we have explicit 64 bit support. I assume that this works on 32 bit platforms as well as an 64 bit platforms? 32 bit backends were the main problem when I tried to build code generation support some years ago, as suddenly everything needed to be 64 bit long in the CG interfaces. > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head just so that it gets some > testing, but perhaps that is premature. I can confirm a complete > bootstrap via "do-cm3-std.sh" that appears to produce perfectly > functional executables, including mentor, etc. Well, as there are no other major projects ongoing in development as far as I know there principally is no need for special care. If you can produce a working core system on two or three target platforms and provide upgrading instructions, we can put it in the main trunk. I'd strongly suggest to tag _everything_ before and after commit of the new code though, for example with cvs tag devel_LONGINT_start cvs commit cvs tag devel_LONGINT_RC01 just to make sure that we can easily revert to prior versions. We'll have to update the M3 language specs, too, and put up some HTML documentation on the servers. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Thu Jul 19 15:13:05 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 08:13:05 -0500 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F6361.9010407@wichita.edu> I'll volunteer to do the update to the language definition, as that is an interest of mine. Tony Hosking wrote: > I've successfully bootstrapped a CM3 compiler that supports LONGINT as > a 64-bit integer type (equivalent to "long long" in C) in addition to > INTEGER (same as "long" in C). This will be useful for simplifying > interfaces to C library routines that expect to be able to treat 64-bit > integers such as "off_t" for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type (I'm > not sure this would ever be a good idea) so it cannot be used to index > arrays, define enumerations etc., though the simple operations ABS, > MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, > assignment, are all supported. This includes changes to m3core (with > support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) > and libm3 for Pickle2, as well as to m3middle, m3front, and the > gcc-based compiler backend. There is still work that needs to be done > to support and test all the other M3 tools such as network objects, > etc., with support and testing needed in m3tk for the new type, as well > as in other tools like m3browser. > > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head just so that it gets some testing, > but perhaps that is premature. I can confirm a complete bootstrap via > "do-cm3-std.sh" that appears to produce perfectly functional > executables, including mentor, etc. > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 16:33:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 10:33:37 -0400 Subject: [M3devel] LONGINT In-Reply-To: <20070719062350.GA12517@elegosoft.com> References: <20070719062350.GA12517@elegosoft.com> Message-ID: On Jul 19, 2007, at 2:23 AM, Olaf Wagner wrote: > On Wed, Jul 18, 2007 at 11:53:38PM -0400, Tony Hosking wrote: >> I've successfully bootstrapped a CM3 compiler that supports LONGINT >> as a 64-bit integer type (equivalent to "long long" in C) in addition >> to INTEGER (same as "long" in C). This will be useful for >> simplifying interfaces to C library routines that expect to be able >> to treat 64-bit integers such as "off_t" for lseek, etc. >> >> Currently, the compiler does not treat LONGINT as an ordinal type >> (I'm not sure this would ever be a good idea) so it cannot be used to >> index arrays, define enumerations etc., though the simple operations >> ABS, MAX, MIN, addition, comparisons, MOD, multiplication, >> subtraction, assignment, are all supported. This includes changes to >> m3core (with support for Long.T similar to Word.T, plus RTTipe and >> RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, >> m3front, and the gcc-based compiler backend. There is still work >> that needs to be done to support and test all the other M3 tools such >> as network objects, etc., with support and testing needed in m3tk for >> the new type, as well as in other tools like m3browser. > > This sounds great! As this topic had been discussed several times, > and nothing ever came of it, I'd rather thought that it wouldn't > be different this time. So at last we have explicit 64 bit support. > I assume that this works on 32 bit platforms as well as an 64 bit > platforms? 32 bit backends were the main problem when I tried to > build code generation support some years ago, as suddenly everything > needed to be 64 bit long in the CG interfaces. What I did was to allow both INTEGER precision and LONGINT precision in M3CG/CG much along the lines of the various floating point precisions (REAL, LONGREAL, EXTENDED). It did require pushing support for these alternatives all the way through to the back-end though the changes are more cosmetic than major refactoring. CM3 is a pretty clean compiler in that respect. > >> How best should I proceed to get this out to the community. I am >> tempted to push it into the CVS head just so that it gets some >> testing, but perhaps that is premature. I can confirm a complete >> bootstrap via "do-cm3-std.sh" that appears to produce perfectly >> functional executables, including mentor, etc. > > Well, as there are no other major projects ongoing in development > as far as I know there principally is no need for special care. > If you can produce a working core system on two or three target > platforms and provide upgrading instructions, we can put it in the > main trunk. I'd strongly suggest to tag _everything_ before and > after commit of the new code though, for example with > > cvs tag devel_LONGINT_start > cvs commit > cvs tag devel_LONGINT_RC01 > > just to make sure that we can easily revert to prior versions. OK, I'll do this. > > We'll have to update the M3 language specs, too, and put up > some HTML documentation on the servers. Yes, indeed. I would be keen to get a clean integration of LONGINT in the specs that makes sense. My biggest question for now is whether we should consider LONGINT as an ordinal type or not. Perhaps there need to be two different classes of ordinal type with different base types (INTEGER and LONGINT). > > Thanks for all the work, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 > Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 23 45 869 fax: +49 30 > 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | > Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From hosking at cs.purdue.edu Thu Jul 19 16:34:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 10:34:22 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469F6361.9010407@wichita.edu> References: <469F6361.9010407@wichita.edu> Message-ID: <6D9BD083-9E4A-4C64-A1FB-5F840D28971E@cs.purdue.edu> On Jul 19, 2007, at 9:13 AM, Rodney M. Bates wrote: > I'll volunteer to do the update to the language definition, as that > is an > interest of mine. Great! Let's try to flesh this out soon so I can try to get the compiler up to speed with what we spec out. > > Tony Hosking wrote: >> I've successfully bootstrapped a CM3 compiler that supports >> LONGINT as a 64-bit integer type (equivalent to "long long" in C) >> in addition to INTEGER (same as "long" in C). This will be >> useful for simplifying interfaces to C library routines that >> expect to be able to treat 64-bit integers such as "off_t" for >> lseek, etc. >> Currently, the compiler does not treat LONGINT as an ordinal type >> (I'm not sure this would ever be a good idea) so it cannot be used >> to index arrays, define enumerations etc., though the simple >> operations ABS, MAX, MIN, addition, comparisons, MOD, >> multiplication, subtraction, assignment, are all supported. This >> includes changes to m3core (with support for Long.T similar to >> Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, >> as well as to m3middle, m3front, and the gcc-based compiler >> backend. There is still work that needs to be done to support >> and test all the other M3 tools such as network objects, etc., >> with support and testing needed in m3tk for the new type, as well >> as in other tools like m3browser. >> How best should I proceed to get this out to the community. I am >> tempted to push it into the CVS head just so that it gets some >> testing, but perhaps that is premature. I can confirm a complete >> bootstrap via "do-cm3-std.sh" that appears to produce perfectly >> functional executables, including mentor, etc. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 17:27:48 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 11:27:48 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> References: <200707170731.l6H7VidO030375@camembert.async.caltech.edu> Message-ID: 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=, M3_CVvbAZ_session=0x1f93290, > M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', > M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid= 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=, > M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Thu Jul 19 17:31:23 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 11:31:23 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: My LONGINT implementation addresses many of your concerns. The LONGINT space is segregated from the INT space. I want to come up with an implementation that also permits ordinals based on LONGINT in addition to the current system of ordinals based on INTEGER. This requires revisiting the language spec and pushing through the implications. I'm going to look at that briefly before moving on to fixing user-level threading for all targets. On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: > Hello everyone, > > I have read the various proposals for supporting integers of different > bit sizes and am getting a little worried that they are running > away from the traditional Modula-3 simplicity. As far as I know, > there is very little in Modula-3 that depends on the actual size > in bits of INTEGERs and CARDINALs. It doesn't seem to me to make > much sense to introduce types like Int32.T and Int64.T and then > make the definition Int32.T = INTEGER (on one platform) and Int64.T > = INTEGER (on another platform). I'm wondering if it would instead > be possible to introduce a new group of types in the sense that > Modula-3 now has integer types and floating-point types, and call > these types "fixed width" or "specified width" types. Conversions > between these types and INTEGER or CARDINAL would have to be done > using functions (operators) that are the analogs of FLOAT, ROUND, > etc. Standard arithmetic operators would be overloaded just like > they are today for integers and floating-point numbers. Am I just > duplicating someone else's proposal here? Perhaps this proposal > doesn't address everything one might want to do with these extended- > size types? > > Maybe I am just dreaming about getting Modula-3 running on a > DECsystem-20 with 36-bit integers...with pickles that are > interchangeable > with i386 pickles, of course. > > What do people want to do with these extended-size types anyhow? > It seems good to me that INTEGER is the largest type that I can > expect my processor to calculate efficiently with. I would use > BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible > and write my code to be flexible about the BYTE/BITSIZE... but OK, > I can see the rationale for hiding all this in the compiler (and > inlining everything) in the few cases where I might want four-function > arithmetic on (specifically) 64- or 128-bit integers. > > Mika > > Darko writes: >> Actually I stated the wrong reason for that one, it's really an >> argument against mixed integer assignment. >> >> And saying that it looks right from the C/C++ point of view is pretty >> damning... >> >> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >> >>> Mail from unsubscribed address forwarded to the list... >>> ---------------------------- Original Message >>> ---------------------------- >>> Subject: Re: A nonnative 64-bit language proposal >>> From: hendrik at topoi.pooq.com >>> Date: Wed, October 25, 2006 14:22 >>> To: m3devel at elegosoft.com >>> -------------------------------------------------------------------- >>> -- >>> ---- >>> >>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>> >>>> For your example to compute as an integer even if that overflows >>>> and >>>> it wouldn't as a longint seems right from my C/C++ point of view. >>> >>> I've always thought C/C++ were badly wrong on this one, even >>> from their own archaic low-level machine-oriented viewpoint. >>> Most computers have integer multiply instructions that return a >>> double-length product. >>> >>> -- hendrik >>> >>> From rodney.bates at wichita.edu Thu Jul 19 19:34:13 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 12:34:13 -0500 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: <469FA095.2000404@wichita.edu> Tony Hosking wrote: > My LONGINT implementation addresses many of your concerns. The LONGINT > space is segregated from the INT space. I want to come up with an > implementation that also permits ordinals based on LONGINT in addition > to the current system of ordinals based on INTEGER. This requires > revisiting the language spec and pushing through the implications. I'm > going to look at that briefly before moving on to fixing user-level > threading for all targets. > By "ordinals", do you mean enumerations? Subranges?. In the language definition, ordinals refers to both the above, plus INTEGER, with CHAR and BOOLEAN being enumerations. It is hard to image a use for enumerations with more than 2^32 values. As I recall, I was thinking this would add quite a bit of complexity to the language for negligible benefit. Subranges of LONGINT seem entirely useful and make for consistency. From a language definition standpoint, I think these just about fall into place with very little change. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rcoleburn at scires.com Thu Jul 19 20:56:16 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 19 Jul 2007 14:56:16 -0400 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F7BAD.1E75.00D7.1@scires.com> Tony: I'd like to better understand the implications of your change as I do use LONGINT as an index in some applications. 1. On a computer with a 32-bit word size, will LONGINT be 32 bits or 64 bits? 2. I assume on a computer with a 64-bit word size, LONGINT will be 64 bits. Is there an option to get a 32-bit integer on these machines? 3. Would it make sense to keep LONGINT at 32-bits and make a new type, say LONGINT64, at 64-bits? Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> Tony Hosking 7/18/2007 11:53 PM >>> I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Jul 19 21:23:54 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:23:54 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FA095.2000404@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> Message-ID: Here are my notes from a run through the language spec. Next step is to flesh out the additional bits in the compiler beyond what I announced yesterday. I would appreciate any feedback you can give as I look into this. 3. TYPES -Ordinal Types: There are three kinds of ordinal types: enumerations, subranges, and integers. There are two integer types, which in order of increasing range and precision are INTEGER and LONGINT. The base type of an ordinal value 'v' is its type (INTEGER or LONGINT) if 'v' is an integer, otherwise it is the unique enumeration type that contains v. Subranges may have base type LONGINT. FIRST, LAST and NUMBER work for LONGINT. LONGINT is predeclared. Should the subrange [0..LAST(LONGINT)] be given a predeclared name? LONGCARD? -Array Types: Arrays may only be indexed by ordinals having an underlying INTEGER base type. [Otherwise, it will be difficult deciding the index type for open arrays.] -Set Types: It seems reasonable that SET OF Base, where the base type for Base is LONGINT, should be allowed. The restrictons on the number of elements in the base set remain (i.e., SET OF [0L..1023L] for elements having base type LONGINT will be practical, but not SET OF LONGINT). -Subtyping Rules: These remain the same for ordinals having LONGINT base type. 4. STATEMENTS. -Assignment: Since INTEGER and LONGINT have different base types they are not assignable. -For: FOR statements will function with LONGINT-based index types: FOR id := first TO last BY step DO S END where 'id' is an identifier, 'first' and 'last' are ordinal expressions with the same base type (e.g., LONGINT), step is an integer-valued expression of type INTEGER or LONGINT and S is a statement. If omitted 'step' defaults to 1 or 1L, depending on the base type of the loop bounds 'first' and 'last'. If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it should be rewritten as a WHILE loop to avoid overflow. -Case: CASE statements may take an expression whose type is an ordinal type with base type LONGINT. -Inc and Dec: INC and DEC function for both INTEGER-based and LONGINT-based ordinals. 7. EXPRESSIONS -Conventions for describing operations: The class 'Integer' will be used to describe the type class consisting of both INTEGER and LONGINT (similar to the use of 'Float'). -Numeric literals: Numeric literals denote constant non-negative integers or reals. The types of these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. A literal LONGINT has the same form as a literal INTEGER, except that it is suffixed with the character 'L'. Thus the LONGINT having value zero would be written '0L'. Moreover, if no explicit base is present, the value of the literal must be at most LAST(LONGINT). If an explicit base is present, the value of the literal must be less than '2^Long.Size', and its interpretation uses the convention of the 'Long' interface. -Arithmetic operations: We adjust the arithmetic operations as follows, where the type class 'Integer' can be one of INTEGER or LONGINT, FloatType represents the type of a type variable taking one of the values REAL, LONGREAL, or EXTENDED, and IntType represents the type of a type variable taking one of the values INTEGER or LONGINT. prefix + (x: Integer) : Integer (x: Float) : Float infix + (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set prefix - (x: Integer) : Integer (x: Float) : Float infix - (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set infix * (x,y: Integer): Integer (x,y: Float) : Float (x,y: Set) : Set infix / (x,y: Float) : Float (x,y: Set) : Set infix DIV (x,y: Integer): Integer infix MOD (x,y: Integer): Integer (x,y: Float) : Float ABS (x: Integer) : Integer (x: Float) : Float FLOAT (x: Integer; T: FloatType := REAL): T (x: Float; T: FloatType := REAL): T FLOOR (x: Float; T: IntType := INTEGER) : T CEILING (x: Float; T: IntType := INTEGER) : T ROUND (r: Float; T: IntType := INTEGER) : T TRUNC (r: Float; T: IntType := INTEGER) : T MAX, MIN (x,y: Ordinal) : Ordinal (x,y: Float) : Float -Relations These functions as expected for LONGINT. -Type operations ORD (element: Ordinal): Integer VAL (i: Integer; T: OrdinalType): T These function as expected, except that ORD returns INTEGER for elements of enumeration types. Otherwise, ORD returns an integer of the same base type as the element. Similarly, for VAL, if T is an enumeration type, then i must be an INTEGER. Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then ORD(n) = VAL(n, T: IntType): = n It is a static error if 'n' is not of type 'T'. NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = LONGINT (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT (A: FixedArrayType): CARDINAL (a: Array) : CARDINAL FIRST (T: OrdinalType) : BaseType(T) (T: FloatType) : T (A: FixedArrayType): BaseType(IndexType(A)) (a: Array) : BaseType(IndexType(a)) LAST (T: OrdinalType) : BaseType(T) (T: FloatType) : T (A: FixedArrayType): BaseType(IndexType(A)) (a: Array) : BaseType(IndexType(a)) BITSIZE (x: Any) : CARDINAL (T: Type): CARDINAL BYTESIZE (x: Any) : CARDINAL (T: Type): CARDINAL ADRSIZE (x: Any) : CARDINAL (T: Type): CARDINAL 9. REQUIRED INTERFACES There is an additional required interface 'Long', analogous to 'Word' except that Long.T = LONGINT On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> My LONGINT implementation addresses many of your concerns. The >> LONGINT space is segregated from the INT space. I want to come >> up with an implementation that also permits ordinals based on >> LONGINT in addition to the current system of ordinals based on >> INTEGER. This requires revisiting the language spec and pushing >> through the implications. I'm going to look at that briefly >> before moving on to fixing user-level threading for all targets. > > By "ordinals", do you mean enumerations? Subranges?. In the language > definition, ordinals refers to both the above, plus INTEGER, with > CHAR and > BOOLEAN being enumerations. > > It is hard to image a use for enumerations with more than 2^32 values. > As I recall, I was thinking this would add quite a bit of > complexity to > the language for negligible benefit. > > Subranges of LONGINT seem entirely useful and make for consistency. > From a language definition standpoint, I think these just about fall > into place with very little change. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Thu Jul 19 21:31:54 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:31:54 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> Message-ID: Yes, I will make bootstrapped compilers available in the usual place. Note that as soon as I check in the updates to CVS then old bootstrap compilers will no longer be able to compile m3core, since it mentions the type LONGINT in the Long.i3 interface. Building with a compiler that supports LONGINT will involve the following bootstrap process: 1. Build and ship the old versions of m3core and libm3. 2. Build and ship m3middle, m3linker, m3front, m3quake, cm3 3. Build and ship the new version of the sources via do-cm3-std.sh using the compiler from step 2 (in INSTALL_ROOT/pkg/cm3/TARGET/cm3). Easiest way to do this is to "export CM3=INSTALL_ROOT/pkg/cm3/ TARGET/cm3" (where INSTALL_ROOT and TARGET match your system) and then execute: do-cm3-std.sh realclean do-cm3-std.sh buildship from the scripts sub-directory of a clean CVS checkout I'll send a message once I have compilers available on my ftp site. On Jul 19, 2007, at 2:41 PM, Darko wrote: > This really is great stuff Tony, thanks for doing the hard yards. > Will you be making a build of this available in your usual spot? > > I'd like to try this out for a while and look for creative ways to > make it break (no offence intended) and get a feel for where it > needs to be extended. In the spirit of the M3 founding fathers, I > think we need some experience with this and then look at the > simplest and smallest change we can do to support what is missing. > > Cheers, > Darko. > > > On 19/07/2007, at 5:31 PM, Tony Hosking wrote: > >> My LONGINT implementation addresses many of your concerns. The >> LONGINT space is segregated from the INT space. I want to come up >> with an implementation that also permits ordinals based on LONGINT >> in addition to the current system of ordinals based on INTEGER. >> This requires revisiting the language spec and pushing through the >> implications. I'm going to look at that briefly before moving on >> to fixing user-level threading for all targets. >> >> On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: >> >>> Hello everyone, >>> >>> I have read the various proposals for supporting integers of >>> different >>> bit sizes and am getting a little worried that they are running >>> away from the traditional Modula-3 simplicity. As far as I know, >>> there is very little in Modula-3 that depends on the actual size >>> in bits of INTEGERs and CARDINALs. It doesn't seem to me to make >>> much sense to introduce types like Int32.T and Int64.T and then >>> make the definition Int32.T = INTEGER (on one platform) and Int64.T >>> = INTEGER (on another platform). I'm wondering if it would instead >>> be possible to introduce a new group of types in the sense that >>> Modula-3 now has integer types and floating-point types, and call >>> these types "fixed width" or "specified width" types. Conversions >>> between these types and INTEGER or CARDINAL would have to be done >>> using functions (operators) that are the analogs of FLOAT, ROUND, >>> etc. Standard arithmetic operators would be overloaded just like >>> they are today for integers and floating-point numbers. Am I just >>> duplicating someone else's proposal here? Perhaps this proposal >>> doesn't address everything one might want to do with these extended- >>> size types? >>> >>> Maybe I am just dreaming about getting Modula-3 running on a >>> DECsystem-20 with 36-bit integers...with pickles that are >>> interchangeable >>> with i386 pickles, of course. >>> >>> What do people want to do with these extended-size types anyhow? >>> It seems good to me that INTEGER is the largest type that I can >>> expect my processor to calculate efficiently with. I would use >>> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible >>> and write my code to be flexible about the BYTE/BITSIZE... but OK, >>> I can see the rationale for hiding all this in the compiler (and >>> inlining everything) in the few cases where I might want four- >>> function >>> arithmetic on (specifically) 64- or 128-bit integers. >>> >>> Mika >>> >>> Darko writes: >>>> Actually I stated the wrong reason for that one, it's really an >>>> argument against mixed integer assignment. >>>> >>>> And saying that it looks right from the C/C++ point of view is >>>> pretty >>>> damning... >>>> >>>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >>>> >>>>> Mail from unsubscribed address forwarded to the list... >>>>> ---------------------------- Original Message >>>>> ---------------------------- >>>>> Subject: Re: A nonnative 64-bit language proposal >>>>> From: hendrik at topoi.pooq.com >>>>> Date: Wed, October 25, 2006 14:22 >>>>> To: m3devel at elegosoft.com >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>> ---- >>>>> >>>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>>>> >>>>>> For your example to compute as an integer even if that >>>>>> overflows and >>>>>> it wouldn't as a longint seems right from my C/C++ point of view. >>>>> >>>>> I've always thought C/C++ were badly wrong on this one, even >>>>> from their own archaic low-level machine-oriented viewpoint. >>>>> Most computers have integer multiply instructions that return a >>>>> double-length product. >>>>> >>>>> -- hendrik >>>>> >>>>> >> From hosking at cs.purdue.edu Thu Jul 19 21:44:18 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 15:44:18 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469F7BAD.1E75.00D7.1@scires.com> References: <469F7BAD.1E75.00D7.1@scires.com> Message-ID: <7C096B2E-9366-4CC0-A03D-B06BFAF40FF8@cs.purdue.edu> On Jul 19, 2007, at 2:56 PM, Randy Coleburn wrote: > Tony: > > I'd like to better understand the implications of your change as I > do use LONGINT as an index in some applications. In that case, what is the index type of an open array: ARRAY OF X? I assume that dope vectors for open arrays will need to indicate the index type. Moreover, code compiled to manipulate ARRAY OF X will need to cope with dynamically-determined index types. My inclination is to avoid this pain by prohibiting ordinals with base type LONGINT from being used as the index type for arrays. > > 1. On a computer with a 32-bit word size, will LONGINT be 32 bits > or 64 bits? LONGINT will be the same as C "long long" which is 64 bits on a 32- bit machine. INTEGER will continue to be the same as C "long" which is 32 bits on a 32-bit machine. On a 64-bit machine, both INTEGER and LONGINT will be 64 bits. > 2. I assume on a computer with a 64-bit word size, LONGINT will be > 64 bits. Is there an option to get a 32-bit integer on these > machines? What's wrong with "BITS 32 FOR [-16_80000000 .. 16_7fffffff]"? > 3. Would it make sense to keep LONGINT at 32-bits and make a new > type, say LONGINT64, at 64-bits? I don't think anyone should make any assumption in portable code about LONGINT and INTEGER other than that BITSIZE(INTEGER) <= BITSIZE(LONGINT) When assuming a given target I think it is reasonable to assume: BITSIZE(INTEGER) = sizeof (long) BITSIZE(LONGINT) = sizeof (long long) so that we have a convenient mapping to C header files and interfaces. > > Regards, > Randy > > Randy C. Coleburn > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." > > >>> Tony Hosking 7/18/2007 11:53 PM >>> > I've successfully bootstrapped a CM3 compiler that supports LONGINT > as a 64-bit integer type (equivalent to "long long" in C) in addition > to INTEGER (same as "long" in C). This will be useful for > simplifying interfaces to C library routines that expect to be able > to treat 64-bit integers such as "off_t" ! for lseek, etc. > > Currently, the compiler does not treat LONGINT as an ordinal type > (I'm not sure this would ever be a good idea) so it cannot be used to > index arrays, define enumerations etc., though the simple operations > ABS, MAX, MIN, addition, comparisons, MOD, multiplication, > subtraction, assignment, are all supported. This includes changes to > m3core (with support for Long.T similar to Word.T, plus RTTipe and > RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, > m3front, and the gcc-based compiler backend. There is still work > that needs to be done to support and test all the other M3 tools such > as network objects, etc., with support and testing needed in m3tk for > the new type, as well as in other tools like m3browser. > > How best should I proceed to get this out to the community. I am > tempted to push it into the CVS head jus! t so that it gets some > testing, but perhaps that is prematur e. I can confirm a complete > bootstrap via "do-cm3-std.sh" that appears to produce perfectly > functional executables, including mentor, etc. > > From darko at darko.org Thu Jul 19 22:23:27 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 22:23:27 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> Message-ID: <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> Have I missed something or is there no way to assign between INTEGER and LONGINT? Is there an explicit conversion function that I've overlooked? Would assignment be so bad here since there would be an implicit range check, much like when you assign between two overlapping subranges? In a sense these two types are integer subranges of an abstract integer type containing all integers. n 19/07/2007, at 9:23 PM, Tony Hosking wrote: > Here are my notes from a run through the language spec. Next step > is to flesh out the additional bits in the compiler beyond what I > announced yesterday. I would appreciate any feedback you can give > as I look into this. > > 3. TYPES > > -Ordinal Types: > > There are three kinds of ordinal types: enumerations, subranges, and > integers. There are two integer types, which in order of > increasing range and > precision are INTEGER and LONGINT. > > The base type of an ordinal value 'v' is its type (INTEGER or > LONGINT) if 'v' > is an integer, otherwise it is the unique enumeration type that > contains v. > > Subranges may have base type LONGINT. > > FIRST, LAST and NUMBER work for LONGINT. > > LONGINT is predeclared. > > Should the subrange [0..LAST(LONGINT)] be given a predeclared > name? LONGCARD? > > -Array Types: > > Arrays may only be indexed by ordinals having an underlying INTEGER > base type. > [Otherwise, it will be difficult deciding the index type for open > arrays.] > > -Set Types: > > It seems reasonable that SET OF Base, where the base type for Base > is LONGINT, > should be allowed. The restrictons on the number of elements in > the base set > remain (i.e., SET OF [0L..1023L] for elements having base type > LONGINT will be > practical, but not SET OF LONGINT). > > -Subtyping Rules: > > These remain the same for ordinals having LONGINT base type. > > > 4. STATEMENTS. > > -Assignment: > > Since INTEGER and LONGINT have different base types they are not > assignable. > > -For: > > FOR statements will function with LONGINT-based index types: > > FOR id := first TO last BY step DO S END > > where 'id' is an identifier, 'first' and 'last' are ordinal > expressions with > the same base type (e.g., LONGINT), step is an integer-valued > expression of > type INTEGER or LONGINT and S is a statement. If omitted 'step' > defaults to 1 > or 1L, depending on the base type of the loop bounds 'first' and > 'last'. > > If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it > should be rewritten as a WHILE loop to avoid overflow. > > -Case: > > CASE statements may take an expression whose type is an ordinal > type with base > type LONGINT. > > -Inc and Dec: > > INC and DEC function for both INTEGER-based and LONGINT-based > ordinals. > > 7. EXPRESSIONS > > -Conventions for describing operations: > > The class 'Integer' will be used to describe the type class > consisting of both > INTEGER and LONGINT (similar to the use of 'Float'). > > -Numeric literals: > > Numeric literals denote constant non-negative integers or reals. > The types of > these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. > > A literal LONGINT has the same form as a literal INTEGER, except > that it is > suffixed with the character 'L'. Thus the LONGINT having value > zero would be > written '0L'. Moreover, if no explicit base is present, the value > of the > literal must be at most LAST(LONGINT). If an explicit base is > present, the > value of the literal must be less than '2^Long.Size', and its > interpretation > uses the convention of the 'Long' interface. > > -Arithmetic operations: > > We adjust the arithmetic operations as follows, where the type > class 'Integer' > can be one of INTEGER or LONGINT, FloatType represents the type of > a type > variable taking one of the values REAL, LONGREAL, or EXTENDED, and > IntType > represents the type of a type variable taking one of the values > INTEGER or LONGINT. > > prefix + (x: Integer) : Integer > (x: Float) : Float > > infix + (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > prefix - (x: Integer) : Integer > (x: Float) : Float > > infix - (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > infix * (x,y: Integer): Integer > (x,y: Float) : Float > (x,y: Set) : Set > > infix / (x,y: Float) : Float > (x,y: Set) : Set > > infix DIV (x,y: Integer): Integer > > infix MOD (x,y: Integer): Integer > (x,y: Float) : Float > > ABS (x: Integer) : Integer > (x: Float) : Float > > FLOAT (x: Integer; T: FloatType := REAL): T > (x: Float; T: FloatType := REAL): T > > FLOOR (x: Float; T: IntType := INTEGER) : T > CEILING (x: Float; T: IntType := INTEGER) : T > > ROUND (r: Float; T: IntType := INTEGER) : T > TRUNC (r: Float; T: IntType := INTEGER) : T > > MAX, MIN (x,y: Ordinal) : Ordinal > (x,y: Float) : Float > > -Relations > > These functions as expected for LONGINT. > > -Type operations > > ORD (element: Ordinal): Integer > VAL (i: Integer; T: OrdinalType): T > > These function as expected, except that ORD returns INTEGER for > elements of > enumeration types. Otherwise, ORD returns an integer of the same > base type as > the element. Similarly, for VAL, if T is an enumeration type, then > i must be > an INTEGER. > > Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then > > ORD(n) = VAL(n, T: IntType): = n > > It is a static error if 'n' is not of type 'T'. > > NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = > LONGINT > (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT > (A: FixedArrayType): CARDINAL > (a: Array) : CARDINAL > > FIRST (T: OrdinalType) : BaseType(T) > (T: FloatType) : T > (A: FixedArrayType): BaseType(IndexType(A)) > (a: Array) : BaseType(IndexType(a)) > LAST (T: OrdinalType) : BaseType(T) > (T: FloatType) : T > (A: FixedArrayType): BaseType(IndexType(A)) > (a: Array) : BaseType(IndexType(a)) > > BITSIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > BYTESIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > ADRSIZE (x: Any) : CARDINAL > (T: Type): CARDINAL > > 9. REQUIRED INTERFACES > > There is an additional required interface 'Long', analogous to > 'Word' except that > > Long.T = LONGINT > > > On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: > >> >> >> Tony Hosking wrote: >>> My LONGINT implementation addresses many of your concerns. The >>> LONGINT space is segregated from the INT space. I want to come >>> up with an implementation that also permits ordinals based on >>> LONGINT in addition to the current system of ordinals based on >>> INTEGER. This requires revisiting the language spec and pushing >>> through the implications. I'm going to look at that briefly >>> before moving on to fixing user-level threading for all targets. >> >> By "ordinals", do you mean enumerations? Subranges?. In the >> language >> definition, ordinals refers to both the above, plus INTEGER, with >> CHAR and >> BOOLEAN being enumerations. >> >> It is hard to image a use for enumerations with more than 2^32 >> values. >> As I recall, I was thinking this would add quite a bit of >> complexity to >> the language for negligible benefit. >> >> Subranges of LONGINT seem entirely useful and make for consistency. >> From a language definition standpoint, I think these just about fall >> into place with very little change. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > From hosking at cs.purdue.edu Thu Jul 19 22:26:38 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 16:26:38 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> Message-ID: <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> This is a good question. I would assume that conversion must be explicit to fit with the M3 philosophy. It would make sense to have a conversion operation that performs the appropriate range check? Any ideas for a name for the operation. On Jul 19, 2007, at 4:23 PM, Darko wrote: > Have I missed something or is there no way to assign between > INTEGER and LONGINT? Is there an explicit conversion function that > I've overlooked? Would assignment be so bad here since there would > be an implicit range check, much like when you assign between two > overlapping subranges? In a sense these two types are integer > subranges of an abstract integer type containing all integers. > > > n 19/07/2007, at 9:23 PM, Tony Hosking wrote: > >> Here are my notes from a run through the language spec. Next step >> is to flesh out the additional bits in the compiler beyond what I >> announced yesterday. I would appreciate any feedback you can give >> as I look into this. >> >> 3. TYPES >> >> -Ordinal Types: >> >> There are three kinds of ordinal types: enumerations, subranges, and >> integers. There are two integer types, which in order of >> increasing range and >> precision are INTEGER and LONGINT. >> >> The base type of an ordinal value 'v' is its type (INTEGER or >> LONGINT) if 'v' >> is an integer, otherwise it is the unique enumeration type that >> contains v. >> >> Subranges may have base type LONGINT. >> >> FIRST, LAST and NUMBER work for LONGINT. >> >> LONGINT is predeclared. >> >> Should the subrange [0..LAST(LONGINT)] be given a predeclared >> name? LONGCARD? >> >> -Array Types: >> >> Arrays may only be indexed by ordinals having an underlying >> INTEGER base type. >> [Otherwise, it will be difficult deciding the index type for open >> arrays.] >> >> -Set Types: >> >> It seems reasonable that SET OF Base, where the base type for Base >> is LONGINT, >> should be allowed. The restrictons on the number of elements in >> the base set >> remain (i.e., SET OF [0L..1023L] for elements having base type >> LONGINT will be >> practical, but not SET OF LONGINT). >> >> -Subtyping Rules: >> >> These remain the same for ordinals having LONGINT base type. >> >> >> 4. STATEMENTS. >> >> -Assignment: >> >> Since INTEGER and LONGINT have different base types they are not >> assignable. >> >> -For: >> >> FOR statements will function with LONGINT-based index types: >> >> FOR id := first TO last BY step DO S END >> >> where 'id' is an identifier, 'first' and 'last' are ordinal >> expressions with >> the same base type (e.g., LONGINT), step is an integer-valued >> expression of >> type INTEGER or LONGINT and S is a statement. If omitted 'step' >> defaults to 1 >> or 1L, depending on the base type of the loop bounds 'first' and >> 'last'. >> >> If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it >> should be rewritten as a WHILE loop to avoid overflow. >> >> -Case: >> >> CASE statements may take an expression whose type is an ordinal >> type with base >> type LONGINT. >> >> -Inc and Dec: >> >> INC and DEC function for both INTEGER-based and LONGINT-based >> ordinals. >> >> 7. EXPRESSIONS >> >> -Conventions for describing operations: >> >> The class 'Integer' will be used to describe the type class >> consisting of both >> INTEGER and LONGINT (similar to the use of 'Float'). >> >> -Numeric literals: >> >> Numeric literals denote constant non-negative integers or reals. >> The types of >> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >> >> A literal LONGINT has the same form as a literal INTEGER, except >> that it is >> suffixed with the character 'L'. Thus the LONGINT having value >> zero would be >> written '0L'. Moreover, if no explicit base is present, the value >> of the >> literal must be at most LAST(LONGINT). If an explicit base is >> present, the >> value of the literal must be less than '2^Long.Size', and its >> interpretation >> uses the convention of the 'Long' interface. >> >> -Arithmetic operations: >> >> We adjust the arithmetic operations as follows, where the type >> class 'Integer' >> can be one of INTEGER or LONGINT, FloatType represents the type of >> a type >> variable taking one of the values REAL, LONGREAL, or EXTENDED, and >> IntType >> represents the type of a type variable taking one of the values >> INTEGER or LONGINT. >> >> prefix + (x: Integer) : Integer >> (x: Float) : Float >> >> infix + (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> prefix - (x: Integer) : Integer >> (x: Float) : Float >> >> infix - (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix * (x,y: Integer): Integer >> (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix / (x,y: Float) : Float >> (x,y: Set) : Set >> >> infix DIV (x,y: Integer): Integer >> >> infix MOD (x,y: Integer): Integer >> (x,y: Float) : Float >> >> ABS (x: Integer) : Integer >> (x: Float) : Float >> >> FLOAT (x: Integer; T: FloatType := REAL): T >> (x: Float; T: FloatType := REAL): T >> >> FLOOR (x: Float; T: IntType := INTEGER) : T >> CEILING (x: Float; T: IntType := INTEGER) : T >> >> ROUND (r: Float; T: IntType := INTEGER) : T >> TRUNC (r: Float; T: IntType := INTEGER) : T >> >> MAX, MIN (x,y: Ordinal) : Ordinal >> (x,y: Float) : Float >> >> -Relations >> >> These functions as expected for LONGINT. >> >> -Type operations >> >> ORD (element: Ordinal): Integer >> VAL (i: Integer; T: OrdinalType): T >> >> These function as expected, except that ORD returns INTEGER for >> elements of >> enumeration types. Otherwise, ORD returns an integer of the same >> base type as >> the element. Similarly, for VAL, if T is an enumeration type, >> then i must be >> an INTEGER. >> >> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >> >> ORD(n) = VAL(n, T: IntType): = n >> >> It is a static error if 'n' is not of type 'T'. >> >> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) = >> LONGINT >> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >> (A: FixedArrayType): CARDINAL >> (a: Array) : CARDINAL >> >> FIRST (T: OrdinalType) : BaseType(T) >> (T: FloatType) : T >> (A: FixedArrayType): BaseType(IndexType(A)) >> (a: Array) : BaseType(IndexType(a)) >> LAST (T: OrdinalType) : BaseType(T) >> (T: FloatType) : T >> (A: FixedArrayType): BaseType(IndexType(A)) >> (a: Array) : BaseType(IndexType(a)) >> >> BITSIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> BYTESIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> ADRSIZE (x: Any) : CARDINAL >> (T: Type): CARDINAL >> >> 9. REQUIRED INTERFACES >> >> There is an additional required interface 'Long', analogous to >> 'Word' except that >> >> Long.T = LONGINT >> >> >> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >> >>> >>> >>> Tony Hosking wrote: >>>> My LONGINT implementation addresses many of your concerns. The >>>> LONGINT space is segregated from the INT space. I want to come >>>> up with an implementation that also permits ordinals based on >>>> LONGINT in addition to the current system of ordinals based on >>>> INTEGER. This requires revisiting the language spec and >>>> pushing through the implications. I'm going to look at that >>>> briefly before moving on to fixing user-level threading for all >>>> targets. >>> >>> By "ordinals", do you mean enumerations? Subranges?. In the >>> language >>> definition, ordinals refers to both the above, plus INTEGER, with >>> CHAR and >>> BOOLEAN being enumerations. >>> >>> It is hard to image a use for enumerations with more than 2^32 >>> values. >>> As I recall, I was thinking this would add quite a bit of >>> complexity to >>> the language for negligible benefit. >>> >>> Subranges of LONGINT seem entirely useful and make for consistency. >>> From a language definition standpoint, I think these just about fall >>> into place with very little change. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu >> From darko at darko.org Thu Jul 19 22:33:04 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 22:33:04 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> Message-ID: <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> I actually favour a implicit conversion, which for this particular case I think would be consistent with existing M3 behaviour. On 19/07/2007, at 10:26 PM, Tony Hosking wrote: > This is a good question. I would assume that conversion must be > explicit to fit with the M3 philosophy. It would make sense to > have a conversion operation that performs the appropriate range > check? Any ideas for a name for the operation. > > On Jul 19, 2007, at 4:23 PM, Darko wrote: > >> Have I missed something or is there no way to assign between >> INTEGER and LONGINT? Is there an explicit conversion function that >> I've overlooked? Would assignment be so bad here since there would >> be an implicit range check, much like when you assign between two >> overlapping subranges? In a sense these two types are integer >> subranges of an abstract integer type containing all integers. >> >> >> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >> >>> Here are my notes from a run through the language spec. Next >>> step is to flesh out the additional bits in the compiler beyond >>> what I announced yesterday. I would appreciate any feedback you >>> can give as I look into this. >>> >>> 3. TYPES >>> >>> -Ordinal Types: >>> >>> There are three kinds of ordinal types: enumerations, subranges, and >>> integers. There are two integer types, which in order of >>> increasing range and >>> precision are INTEGER and LONGINT. >>> >>> The base type of an ordinal value 'v' is its type (INTEGER or >>> LONGINT) if 'v' >>> is an integer, otherwise it is the unique enumeration type that >>> contains v. >>> >>> Subranges may have base type LONGINT. >>> >>> FIRST, LAST and NUMBER work for LONGINT. >>> >>> LONGINT is predeclared. >>> >>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>> name? LONGCARD? >>> >>> -Array Types: >>> >>> Arrays may only be indexed by ordinals having an underlying >>> INTEGER base type. >>> [Otherwise, it will be difficult deciding the index type for open >>> arrays.] >>> >>> -Set Types: >>> >>> It seems reasonable that SET OF Base, where the base type for >>> Base is LONGINT, >>> should be allowed. The restrictons on the number of elements in >>> the base set >>> remain (i.e., SET OF [0L..1023L] for elements having base type >>> LONGINT will be >>> practical, but not SET OF LONGINT). >>> >>> -Subtyping Rules: >>> >>> These remain the same for ordinals having LONGINT base type. >>> >>> >>> 4. STATEMENTS. >>> >>> -Assignment: >>> >>> Since INTEGER and LONGINT have different base types they are not >>> assignable. >>> >>> -For: >>> >>> FOR statements will function with LONGINT-based index types: >>> >>> FOR id := first TO last BY step DO S END >>> >>> where 'id' is an identifier, 'first' and 'last' are ordinal >>> expressions with >>> the same base type (e.g., LONGINT), step is an integer-valued >>> expression of >>> type INTEGER or LONGINT and S is a statement. If omitted 'step' >>> defaults to 1 >>> or 1L, depending on the base type of the loop bounds 'first' and >>> 'last'. >>> >>> If the upper bound of the loop is LAST(INTEGER) or LAST(LONGINT), it >>> should be rewritten as a WHILE loop to avoid overflow. >>> >>> -Case: >>> >>> CASE statements may take an expression whose type is an ordinal >>> type with base >>> type LONGINT. >>> >>> -Inc and Dec: >>> >>> INC and DEC function for both INTEGER-based and LONGINT-based >>> ordinals. >>> >>> 7. EXPRESSIONS >>> >>> -Conventions for describing operations: >>> >>> The class 'Integer' will be used to describe the type class >>> consisting of both >>> INTEGER and LONGINT (similar to the use of 'Float'). >>> >>> -Numeric literals: >>> >>> Numeric literals denote constant non-negative integers or reals. >>> The types of >>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>> >>> A literal LONGINT has the same form as a literal INTEGER, except >>> that it is >>> suffixed with the character 'L'. Thus the LONGINT having value >>> zero would be >>> written '0L'. Moreover, if no explicit base is present, the >>> value of the >>> literal must be at most LAST(LONGINT). If an explicit base is >>> present, the >>> value of the literal must be less than '2^Long.Size', and its >>> interpretation >>> uses the convention of the 'Long' interface. >>> >>> -Arithmetic operations: >>> >>> We adjust the arithmetic operations as follows, where the type >>> class 'Integer' >>> can be one of INTEGER or LONGINT, FloatType represents the type >>> of a type >>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>> and IntType >>> represents the type of a type variable taking one of the values >>> INTEGER or LONGINT. >>> >>> prefix + (x: Integer) : Integer >>> (x: Float) : Float >>> >>> infix + (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> prefix - (x: Integer) : Integer >>> (x: Float) : Float >>> >>> infix - (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix * (x,y: Integer): Integer >>> (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix / (x,y: Float) : Float >>> (x,y: Set) : Set >>> >>> infix DIV (x,y: Integer): Integer >>> >>> infix MOD (x,y: Integer): Integer >>> (x,y: Float) : Float >>> >>> ABS (x: Integer) : Integer >>> (x: Float) : Float >>> >>> FLOAT (x: Integer; T: FloatType := REAL): T >>> (x: Float; T: FloatType := REAL): T >>> >>> FLOOR (x: Float; T: IntType := INTEGER) : T >>> CEILING (x: Float; T: IntType := INTEGER) : T >>> >>> ROUND (r: Float; T: IntType := INTEGER) : T >>> TRUNC (r: Float; T: IntType := INTEGER) : T >>> >>> MAX, MIN (x,y: Ordinal) : Ordinal >>> (x,y: Float) : Float >>> >>> -Relations >>> >>> These functions as expected for LONGINT. >>> >>> -Type operations >>> >>> ORD (element: Ordinal): Integer >>> VAL (i: Integer; T: OrdinalType): T >>> >>> These function as expected, except that ORD returns INTEGER for >>> elements of >>> enumeration types. Otherwise, ORD returns an integer of the same >>> base type as >>> the element. Similarly, for VAL, if T is an enumeration type, >>> then i must be >>> an INTEGER. >>> >>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>> >>> ORD(n) = VAL(n, T: IntType): = n >>> >>> It is a static error if 'n' is not of type 'T'. >>> >>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) >>> = LONGINT >>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >>> (A: FixedArrayType): CARDINAL >>> (a: Array) : CARDINAL >>> >>> FIRST (T: OrdinalType) : BaseType(T) >>> (T: FloatType) : T >>> (A: FixedArrayType): BaseType(IndexType(A)) >>> (a: Array) : BaseType(IndexType(a)) >>> LAST (T: OrdinalType) : BaseType(T) >>> (T: FloatType) : T >>> (A: FixedArrayType): BaseType(IndexType(A)) >>> (a: Array) : BaseType(IndexType(a)) >>> >>> BITSIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> BYTESIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> ADRSIZE (x: Any) : CARDINAL >>> (T: Type): CARDINAL >>> >>> 9. REQUIRED INTERFACES >>> >>> There is an additional required interface 'Long', analogous to >>> 'Word' except that >>> >>> Long.T = LONGINT >>> >>> >>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>> >>>> >>>> >>>> Tony Hosking wrote: >>>>> My LONGINT implementation addresses many of your concerns. >>>>> The LONGINT space is segregated from the INT space. I want to >>>>> come up with an implementation that also permits ordinals >>>>> based on LONGINT in addition to the current system of ordinals >>>>> based on INTEGER. This requires revisiting the language spec >>>>> and pushing through the implications. I'm going to look at >>>>> that briefly before moving on to fixing user-level threading >>>>> for all targets. >>>> >>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>> language >>>> definition, ordinals refers to both the above, plus INTEGER, >>>> with CHAR and >>>> BOOLEAN being enumerations. >>>> >>>> It is hard to image a use for enumerations with more than 2^32 >>>> values. >>>> As I recall, I was thinking this would add quite a bit of >>>> complexity to >>>> the language for negligible benefit. >>>> >>>> Subranges of LONGINT seem entirely useful and make for consistency. >>>> From a language definition standpoint, I think these just about >>>> fall >>>> into place with very little change. >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu >>> > From hosking at cs.purdue.edu Thu Jul 19 22:50:50 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 19 Jul 2007 16:50:50 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: On Jul 19, 2007, at 4:33 PM, Darko wrote: > I actually favour a implicit conversion, which for this particular > case I think would be consistent with existing M3 behaviour. There is no implicit conversion for floats. The danger with implicit conversion for integers is that it would not be portable: you would get different behavior on different machines for the same code. Better to make the conversion explicit so that programmers are prepared for the range check to fail. > > > On 19/07/2007, at 10:26 PM, Tony Hosking wrote: > >> This is a good question. I would assume that conversion must be >> explicit to fit with the M3 philosophy. It would make sense to >> have a conversion operation that performs the appropriate range >> check? Any ideas for a name for the operation. >> >> On Jul 19, 2007, at 4:23 PM, Darko wrote: >> >>> Have I missed something or is there no way to assign between >>> INTEGER and LONGINT? Is there an explicit conversion function >>> that I've overlooked? Would assignment be so bad here since there >>> would be an implicit range check, much like when you assign >>> between two overlapping subranges? In a sense these two types are >>> integer subranges of an abstract integer type containing all >>> integers. >>> >>> >>> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >>> >>>> Here are my notes from a run through the language spec. Next >>>> step is to flesh out the additional bits in the compiler beyond >>>> what I announced yesterday. I would appreciate any feedback you >>>> can give as I look into this. >>>> >>>> 3. TYPES >>>> >>>> -Ordinal Types: >>>> >>>> There are three kinds of ordinal types: enumerations, subranges, >>>> and >>>> integers. There are two integer types, which in order of >>>> increasing range and >>>> precision are INTEGER and LONGINT. >>>> >>>> The base type of an ordinal value 'v' is its type (INTEGER or >>>> LONGINT) if 'v' >>>> is an integer, otherwise it is the unique enumeration type that >>>> contains v. >>>> >>>> Subranges may have base type LONGINT. >>>> >>>> FIRST, LAST and NUMBER work for LONGINT. >>>> >>>> LONGINT is predeclared. >>>> >>>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>>> name? LONGCARD? >>>> >>>> -Array Types: >>>> >>>> Arrays may only be indexed by ordinals having an underlying >>>> INTEGER base type. >>>> [Otherwise, it will be difficult deciding the index type for >>>> open arrays.] >>>> >>>> -Set Types: >>>> >>>> It seems reasonable that SET OF Base, where the base type for >>>> Base is LONGINT, >>>> should be allowed. The restrictons on the number of elements in >>>> the base set >>>> remain (i.e., SET OF [0L..1023L] for elements having base type >>>> LONGINT will be >>>> practical, but not SET OF LONGINT). >>>> >>>> -Subtyping Rules: >>>> >>>> These remain the same for ordinals having LONGINT base type. >>>> >>>> >>>> 4. STATEMENTS. >>>> >>>> -Assignment: >>>> >>>> Since INTEGER and LONGINT have different base types they are not >>>> assignable. >>>> >>>> -For: >>>> >>>> FOR statements will function with LONGINT-based index types: >>>> >>>> FOR id := first TO last BY step DO S END >>>> >>>> where 'id' is an identifier, 'first' and 'last' are ordinal >>>> expressions with >>>> the same base type (e.g., LONGINT), step is an integer-valued >>>> expression of >>>> type INTEGER or LONGINT and S is a statement. If omitted 'step' >>>> defaults to 1 >>>> or 1L, depending on the base type of the loop bounds 'first' and >>>> 'last'. >>>> >>>> If the upper bound of the loop is LAST(INTEGER) or LAST >>>> (LONGINT), it >>>> should be rewritten as a WHILE loop to avoid overflow. >>>> >>>> -Case: >>>> >>>> CASE statements may take an expression whose type is an ordinal >>>> type with base >>>> type LONGINT. >>>> >>>> -Inc and Dec: >>>> >>>> INC and DEC function for both INTEGER-based and LONGINT-based >>>> ordinals. >>>> >>>> 7. EXPRESSIONS >>>> >>>> -Conventions for describing operations: >>>> >>>> The class 'Integer' will be used to describe the type class >>>> consisting of both >>>> INTEGER and LONGINT (similar to the use of 'Float'). >>>> >>>> -Numeric literals: >>>> >>>> Numeric literals denote constant non-negative integers or reals. >>>> The types of >>>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>>> >>>> A literal LONGINT has the same form as a literal INTEGER, except >>>> that it is >>>> suffixed with the character 'L'. Thus the LONGINT having value >>>> zero would be >>>> written '0L'. Moreover, if no explicit base is present, the >>>> value of the >>>> literal must be at most LAST(LONGINT). If an explicit base is >>>> present, the >>>> value of the literal must be less than '2^Long.Size', and its >>>> interpretation >>>> uses the convention of the 'Long' interface. >>>> >>>> -Arithmetic operations: >>>> >>>> We adjust the arithmetic operations as follows, where the type >>>> class 'Integer' >>>> can be one of INTEGER or LONGINT, FloatType represents the type >>>> of a type >>>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>>> and IntType >>>> represents the type of a type variable taking one of the values >>>> INTEGER or LONGINT. >>>> >>>> prefix + (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> infix + (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> prefix - (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> infix - (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix * (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix / (x,y: Float) : Float >>>> (x,y: Set) : Set >>>> >>>> infix DIV (x,y: Integer): Integer >>>> >>>> infix MOD (x,y: Integer): Integer >>>> (x,y: Float) : Float >>>> >>>> ABS (x: Integer) : Integer >>>> (x: Float) : Float >>>> >>>> FLOAT (x: Integer; T: FloatType := REAL): T >>>> (x: Float; T: FloatType := REAL): T >>>> >>>> FLOOR (x: Float; T: IntType := INTEGER) : T >>>> CEILING (x: Float; T: IntType := INTEGER) : T >>>> >>>> ROUND (r: Float; T: IntType := INTEGER) : T >>>> TRUNC (r: Float; T: IntType := INTEGER) : T >>>> >>>> MAX, MIN (x,y: Ordinal) : Ordinal >>>> (x,y: Float) : Float >>>> >>>> -Relations >>>> >>>> These functions as expected for LONGINT. >>>> >>>> -Type operations >>>> >>>> ORD (element: Ordinal): Integer >>>> VAL (i: Integer; T: OrdinalType): T >>>> >>>> These function as expected, except that ORD returns INTEGER for >>>> elements of >>>> enumeration types. Otherwise, ORD returns an integer of the >>>> same base type as >>>> the element. Similarly, for VAL, if T is an enumeration type, >>>> then i must be >>>> an INTEGER. >>>> >>>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>>> >>>> ORD(n) = VAL(n, T: IntType): = n >>>> >>>> It is a static error if 'n' is not of type 'T'. >>>> >>>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType(T) >>>> = LONGINT >>>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = LONGINT >>>> (A: FixedArrayType): CARDINAL >>>> (a: Array) : CARDINAL >>>> >>>> FIRST (T: OrdinalType) : BaseType(T) >>>> (T: FloatType) : T >>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>> (a: Array) : BaseType(IndexType(a)) >>>> LAST (T: OrdinalType) : BaseType(T) >>>> (T: FloatType) : T >>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>> (a: Array) : BaseType(IndexType(a)) >>>> >>>> BITSIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> BYTESIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> ADRSIZE (x: Any) : CARDINAL >>>> (T: Type): CARDINAL >>>> >>>> 9. REQUIRED INTERFACES >>>> >>>> There is an additional required interface 'Long', analogous to >>>> 'Word' except that >>>> >>>> Long.T = LONGINT >>>> >>>> >>>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>>> >>>>> >>>>> >>>>> Tony Hosking wrote: >>>>>> My LONGINT implementation addresses many of your concerns. >>>>>> The LONGINT space is segregated from the INT space. I want >>>>>> to come up with an implementation that also permits ordinals >>>>>> based on LONGINT in addition to the current system of >>>>>> ordinals based on INTEGER. This requires revisiting the >>>>>> language spec and pushing through the implications. I'm >>>>>> going to look at that briefly before moving on to fixing user- >>>>>> level threading for all targets. >>>>> >>>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>>> language >>>>> definition, ordinals refers to both the above, plus INTEGER, >>>>> with CHAR and >>>>> BOOLEAN being enumerations. >>>>> >>>>> It is hard to image a use for enumerations with more than 2^32 >>>>> values. >>>>> As I recall, I was thinking this would add quite a bit of >>>>> complexity to >>>>> the language for negligible benefit. >>>>> >>>>> Subranges of LONGINT seem entirely useful and make for >>>>> consistency. >>>>> From a language definition standpoint, I think these just about >>>>> fall >>>>> into place with very little change. >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu >>>> >> From darko at darko.org Thu Jul 19 23:23:35 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 23:23:35 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: I think INT and LONG seem pretty intuitive. INT(l: LONGINT): INTEGER; LONG(i: INTEGER): LONGINT; But back on the point, range check failures are a runtime phenomena, so they are an issue at anytime. On 19/07/2007, at 10:50 PM, Tony Hosking wrote: > On Jul 19, 2007, at 4:33 PM, Darko wrote: > >> I actually favour a implicit conversion, which for this particular >> case I think would be consistent with existing M3 behaviour. > > There is no implicit conversion for floats. The danger with > implicit conversion for integers is that it would not be portable: > you would get different behavior on different machines for the same > code. Better to make the conversion explicit so that programmers > are prepared for the range check to fail. > >> >> >> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >> >>> This is a good question. I would assume that conversion must be >>> explicit to fit with the M3 philosophy. It would make sense to >>> have a conversion operation that performs the appropriate range >>> check? Any ideas for a name for the operation. >>> >>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>> >>>> Have I missed something or is there no way to assign between >>>> INTEGER and LONGINT? Is there an explicit conversion function >>>> that I've overlooked? Would assignment be so bad here since >>>> there would be an implicit range check, much like when you >>>> assign between two overlapping subranges? In a sense these two >>>> types are integer subranges of an abstract integer type >>>> containing all integers. >>>> >>>> >>>> n 19/07/2007, at 9:23 PM, Tony Hosking wrote: >>>> >>>>> Here are my notes from a run through the language spec. Next >>>>> step is to flesh out the additional bits in the compiler beyond >>>>> what I announced yesterday. I would appreciate any feedback >>>>> you can give as I look into this. >>>>> >>>>> 3. TYPES >>>>> >>>>> -Ordinal Types: >>>>> >>>>> There are three kinds of ordinal types: enumerations, >>>>> subranges, and >>>>> integers. There are two integer types, which in order of >>>>> increasing range and >>>>> precision are INTEGER and LONGINT. >>>>> >>>>> The base type of an ordinal value 'v' is its type (INTEGER or >>>>> LONGINT) if 'v' >>>>> is an integer, otherwise it is the unique enumeration type that >>>>> contains v. >>>>> >>>>> Subranges may have base type LONGINT. >>>>> >>>>> FIRST, LAST and NUMBER work for LONGINT. >>>>> >>>>> LONGINT is predeclared. >>>>> >>>>> Should the subrange [0..LAST(LONGINT)] be given a predeclared >>>>> name? LONGCARD? >>>>> >>>>> -Array Types: >>>>> >>>>> Arrays may only be indexed by ordinals having an underlying >>>>> INTEGER base type. >>>>> [Otherwise, it will be difficult deciding the index type for >>>>> open arrays.] >>>>> >>>>> -Set Types: >>>>> >>>>> It seems reasonable that SET OF Base, where the base type for >>>>> Base is LONGINT, >>>>> should be allowed. The restrictons on the number of elements >>>>> in the base set >>>>> remain (i.e., SET OF [0L..1023L] for elements having base type >>>>> LONGINT will be >>>>> practical, but not SET OF LONGINT). >>>>> >>>>> -Subtyping Rules: >>>>> >>>>> These remain the same for ordinals having LONGINT base type. >>>>> >>>>> >>>>> 4. STATEMENTS. >>>>> >>>>> -Assignment: >>>>> >>>>> Since INTEGER and LONGINT have different base types they are >>>>> not assignable. >>>>> >>>>> -For: >>>>> >>>>> FOR statements will function with LONGINT-based index types: >>>>> >>>>> FOR id := first TO last BY step DO S END >>>>> >>>>> where 'id' is an identifier, 'first' and 'last' are ordinal >>>>> expressions with >>>>> the same base type (e.g., LONGINT), step is an integer-valued >>>>> expression of >>>>> type INTEGER or LONGINT and S is a statement. If omitted >>>>> 'step' defaults to 1 >>>>> or 1L, depending on the base type of the loop bounds 'first' >>>>> and 'last'. >>>>> >>>>> If the upper bound of the loop is LAST(INTEGER) or LAST >>>>> (LONGINT), it >>>>> should be rewritten as a WHILE loop to avoid overflow. >>>>> >>>>> -Case: >>>>> >>>>> CASE statements may take an expression whose type is an ordinal >>>>> type with base >>>>> type LONGINT. >>>>> >>>>> -Inc and Dec: >>>>> >>>>> INC and DEC function for both INTEGER-based and LONGINT-based >>>>> ordinals. >>>>> >>>>> 7. EXPRESSIONS >>>>> >>>>> -Conventions for describing operations: >>>>> >>>>> The class 'Integer' will be used to describe the type class >>>>> consisting of both >>>>> INTEGER and LONGINT (similar to the use of 'Float'). >>>>> >>>>> -Numeric literals: >>>>> >>>>> Numeric literals denote constant non-negative integers or >>>>> reals. The types of >>>>> these literals are INTEGER, LONGINT, REAL, LONGREAL, and EXTENDED. >>>>> >>>>> A literal LONGINT has the same form as a literal INTEGER, >>>>> except that it is >>>>> suffixed with the character 'L'. Thus the LONGINT having value >>>>> zero would be >>>>> written '0L'. Moreover, if no explicit base is present, the >>>>> value of the >>>>> literal must be at most LAST(LONGINT). If an explicit base is >>>>> present, the >>>>> value of the literal must be less than '2^Long.Size', and its >>>>> interpretation >>>>> uses the convention of the 'Long' interface. >>>>> >>>>> -Arithmetic operations: >>>>> >>>>> We adjust the arithmetic operations as follows, where the type >>>>> class 'Integer' >>>>> can be one of INTEGER or LONGINT, FloatType represents the type >>>>> of a type >>>>> variable taking one of the values REAL, LONGREAL, or EXTENDED, >>>>> and IntType >>>>> represents the type of a type variable taking one of the values >>>>> INTEGER or LONGINT. >>>>> >>>>> prefix + (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> infix + (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> prefix - (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> infix - (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix * (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix / (x,y: Float) : Float >>>>> (x,y: Set) : Set >>>>> >>>>> infix DIV (x,y: Integer): Integer >>>>> >>>>> infix MOD (x,y: Integer): Integer >>>>> (x,y: Float) : Float >>>>> >>>>> ABS (x: Integer) : Integer >>>>> (x: Float) : Float >>>>> >>>>> FLOAT (x: Integer; T: FloatType := REAL): T >>>>> (x: Float; T: FloatType := REAL): T >>>>> >>>>> FLOOR (x: Float; T: IntType := INTEGER) : T >>>>> CEILING (x: Float; T: IntType := INTEGER) : T >>>>> >>>>> ROUND (r: Float; T: IntType := INTEGER) : T >>>>> TRUNC (r: Float; T: IntType := INTEGER) : T >>>>> >>>>> MAX, MIN (x,y: Ordinal) : Ordinal >>>>> (x,y: Float) : Float >>>>> >>>>> -Relations >>>>> >>>>> These functions as expected for LONGINT. >>>>> >>>>> -Type operations >>>>> >>>>> ORD (element: Ordinal): Integer >>>>> VAL (i: Integer; T: OrdinalType): T >>>>> >>>>> These function as expected, except that ORD returns INTEGER for >>>>> elements of >>>>> enumeration types. Otherwise, ORD returns an integer of the >>>>> same base type as >>>>> the element. Similarly, for VAL, if T is an enumeration type, >>>>> then i must be >>>>> an INTEGER. >>>>> >>>>> Thus, if 'n' is an integer of type T (INTEGER or LONGINT) then >>>>> >>>>> ORD(n) = VAL(n, T: IntType): = n >>>>> >>>>> It is a static error if 'n' is not of type 'T'. >>>>> >>>>> NUMBER (T: OrdinalType) : [0..LAST(LONGINT)] if BaseType >>>>> (T) = LONGINT >>>>> (T: OrdinalType) : [0..LAST(INTEGER)] if BaseType(T) = >>>>> LONGINT >>>>> (A: FixedArrayType): CARDINAL >>>>> (a: Array) : CARDINAL >>>>> >>>>> FIRST (T: OrdinalType) : BaseType(T) >>>>> (T: FloatType) : T >>>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>>> (a: Array) : BaseType(IndexType(a)) >>>>> LAST (T: OrdinalType) : BaseType(T) >>>>> (T: FloatType) : T >>>>> (A: FixedArrayType): BaseType(IndexType(A)) >>>>> (a: Array) : BaseType(IndexType(a)) >>>>> >>>>> BITSIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> BYTESIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> ADRSIZE (x: Any) : CARDINAL >>>>> (T: Type): CARDINAL >>>>> >>>>> 9. REQUIRED INTERFACES >>>>> >>>>> There is an additional required interface 'Long', analogous to >>>>> 'Word' except that >>>>> >>>>> Long.T = LONGINT >>>>> >>>>> >>>>> On Jul 19, 2007, at 1:34 PM, Rodney M. Bates wrote: >>>>> >>>>>> >>>>>> >>>>>> Tony Hosking wrote: >>>>>>> My LONGINT implementation addresses many of your concerns. >>>>>>> The LONGINT space is segregated from the INT space. I want >>>>>>> to come up with an implementation that also permits ordinals >>>>>>> based on LONGINT in addition to the current system of >>>>>>> ordinals based on INTEGER. This requires revisiting the >>>>>>> language spec and pushing through the implications. I'm >>>>>>> going to look at that briefly before moving on to fixing >>>>>>> user-level threading for all targets. >>>>>> >>>>>> By "ordinals", do you mean enumerations? Subranges?. In the >>>>>> language >>>>>> definition, ordinals refers to both the above, plus INTEGER, >>>>>> with CHAR and >>>>>> BOOLEAN being enumerations. >>>>>> >>>>>> It is hard to image a use for enumerations with more than 2^32 >>>>>> values. >>>>>> As I recall, I was thinking this would add quite a bit of >>>>>> complexity to >>>>>> the language for negligible benefit. >>>>>> >>>>>> Subranges of LONGINT seem entirely useful and make for >>>>>> consistency. >>>>>> From a language definition standpoint, I think these just >>>>>> about fall >>>>>> into place with very little change. >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------- >>>>>> Rodney M. Bates, retired assistant professor >>>>>> Dept. of Computer Science, Wichita State University >>>>>> Wichita, KS 67260-0083 >>>>>> 316-978-3922 >>>>>> rodney.bates at wichita.edu >>>>> >>> > From rodney.bates at wichita.edu Thu Jul 19 23:33:28 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 16:33:28 -0500 Subject: [M3devel] LONGINT In-Reply-To: <469F7BAD.1E75.00D7.1@scires.com> References: <469F7BAD.1E75.00D7.1@scires.com> Message-ID: <469FD8A8.8070807@wichita.edu> Randy Coleburn wrote: > Tony: > > I'd like to better understand the implications of your change as I do > use LONGINT as an index in some applications. Do you have arrays that need 64-bit subscripts on a 32-bit machine? Allow me the common assumption that both integers and addresses have the native word size on most machines. In this case, most arrays that need 64-bit subscripts would exceed the virtual address space of the machine. Exceptions would require elements of size at most a byte, and overall sizes in excess of half the virtual address space. Even PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the virtual space before 32-bit subscripts ran out. All this seems pretty unlikely. I would favor keeping INTEGER as the type of open array subscripts and not allowing LONGINT to be a fixed array subscript type. It saves a whole lot of language complexity, and doesn't disallow much. If it really mattered, you could still use unsafe techniques for such memory-hogging arrays. This might be a reason to extend unsafe arithmetic on ADDRESS to accept LONGINT second operands. This is actually consistent with the rest of the operator generalizations. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From darko at darko.org Thu Jul 19 23:35:23 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 23:35:23 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FD59A.8020809@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FD59A.8020809@wichita.edu> Message-ID: <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> I agree with you and I strongly agree with Tony's approach to the implementation where the two integer types are not subtypes. The VAL usage would be a bit finicky given how often this would be done in practice, something more concise (like INT and LONG) would be better. On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote: > In my original 64-bit proposal, I made INTEGER # LONGINT, and also > the two > types have no subtype relation (which, I think is what Antony is > saying). > It avoids having a lot of things happen implicitly from other rules > in the > language. > > But then I added a separate rule that these two types and their > subranges > are mutually assignable, subject to the existing assignability > rules that > now apply to a type and its subranges. Namely the RHS value must be > in the > range of the of the LHS type, which sometimes has to be checked at > runtime. > > This allows assignment without explicit conversion, as well as many > other > things, for example, VALUE parameter passing, that require > assignability. > This is consistent with the existing rules for assignments involving > different subranges. > > For explicit conversions (which are probably needed somewhere anyway, > even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit > the existing language well. For consistency, it seems good to allow > ORD(LongIntArg), which is an alternative conversion in one direction. > It may seem unnecessary, but it's not as useless as ORD(IntegerArg), > which we already have. Actually, these extensions of VAL and ORD > fall out of the existing definitions, when LONGINT is an ordinal type. > > Darko wrote: >> I actually favour a implicit conversion, which for this >> particular case I think would be consistent with existing M3 >> behaviour. >> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >>> This is a good question. I would assume that conversion must be >>> explicit to fit with the M3 philosophy. It would make sense to >>> have a conversion operation that performs the appropriate range >>> check? Any ideas for a name for the operation. >>> >>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>> >>>> Have I missed something or is there no way to assign between >>>> INTEGER and LONGINT? Is there an explicit conversion function >>>> that I've overlooked? Would assignment be so bad here since >>>> there would be an implicit range check, much like when you >>>> assign between two overlapping subranges? In a sense these two >>>> types are integer subranges of an abstract integer type >>>> containing all integers. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From darko at darko.org Fri Jul 20 00:02:55 2007 From: darko at darko.org (Darko) Date: Fri, 20 Jul 2007 00:02:55 +0200 Subject: [M3devel] LONGINT In-Reply-To: <469FD8A8.8070807@wichita.edu> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> Message-ID: <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> I think in 64 bit land you get a variety of combinations and possibly the most common is a 32 bit address space with 64 bit integers, since applications seldom need to operate in the larger address space. But I would think it you wouldn't allocate an object bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would be more likely. The only situation where I can think of where this is an issue is using a long integer index in an array of integer proportions, you could handle this using arithmetic, also illustrates where you'd need an implicit conversion: CONST start = 2^63-500; end = 2^63-200; VAR a: ARRAY[0..start-end+1] OF CHAR; BEGIN FOR i := start TO end DO a[INT(i-start)] := 'x' END; Or you could rule that all arrays are of INTEGER size, but may have a LONGINT index. Open arrays would always be integers. This would probably be messy to implement and NUMBER would have a different base to FIRST and LAST. That doesn't sound very good. On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote: > > > Randy Coleburn wrote: >> Tony: >> I'd like to better understand the implications of your change as >> I do use LONGINT as an index in some applications. > > Do you have arrays that need 64-bit subscripts on a 32-bit machine? > > Allow me the common assumption that both integers and addresses have > the native word size on most machines. In this case, most arrays that > need 64-bit subscripts would exceed the virtual address space of the > machine. Exceptions would require elements of size at most a byte, > and overall sizes in excess of half the virtual address space. Even > PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the > virtual space before 32-bit subscripts ran out. All this seems pretty > unlikely. > > I would favor keeping INTEGER as the type of open array subscripts > and not allowing LONGINT to be a fixed array subscript type. It > saves a whole lot of language complexity, and doesn't disallow much. > > If it really mattered, you could still use unsafe techniques for > such memory-hogging arrays. This might be a reason to extend unsafe > arithmetic on ADDRESS to accept LONGINT second operands. This is > actually consistent with the rest of the operator generalizations. >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Jul 20 00:04:14 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 19 Jul 2007 17:04:14 -0500 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> Message-ID: <469FDFDE.9020201@wichita.edu> Tony Hosking wrote: > On Jul 19, 2007, at 4:33 PM, Darko wrote: > >> I actually favour a implicit conversion, which for this particular >> case I think would be consistent with existing M3 behaviour. > > > There is no implicit conversion for floats. The danger with implicit > conversion for integers is that it would not be portable: you would get > different behavior on different machines for the same code. Better to > make the conversion explicit so that programmers are prepared for the > range check to fail. But is this argument any stronger for requiring explicit conversions for INTEGER/LONGINT assignments than for assigning to subranges? Many assignments in the language now, without any type conversion, admit the possibility of RT range errors. And these can be dependent on the size of INTEGER too. Consider: VAR V : [ 0 .. 65535 ] ; VAR I : CARDINAL ; ... V := I DIV 2 ; I think for portability, the principle that the static semantics should be the same for all sizes of INTEGER (and LONGINT too) is as much as we can hope for. Certainly, there are already countless ways the integer size can change the dynamic semantics of a program. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From darko at darko.org Thu Jul 19 20:41:08 2007 From: darko at darko.org (Darko) Date: Thu, 19 Jul 2007 20:41:08 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> Message-ID: <135605BF-259F-4C2C-889F-87C629ED4DF3@darko.org> This really is great stuff Tony, thanks for doing the hard yards. Will you be making a build of this available in your usual spot? I'd like to try this out for a while and look for creative ways to make it break (no offence intended) and get a feel for where it needs to be extended. In the spirit of the M3 founding fathers, I think we need some experience with this and then look at the simplest and smallest change we can do to support what is missing. Cheers, Darko. On 19/07/2007, at 5:31 PM, Tony Hosking wrote: > My LONGINT implementation addresses many of your concerns. The > LONGINT space is segregated from the INT space. I want to come up > with an implementation that also permits ordinals based on LONGINT > in addition to the current system of ordinals based on INTEGER. > This requires revisiting the language spec and pushing through the > implications. I'm going to look at that briefly before moving on > to fixing user-level threading for all targets. > > On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote: > >> Hello everyone, >> >> I have read the various proposals for supporting integers of >> different >> bit sizes and am getting a little worried that they are running >> away from the traditional Modula-3 simplicity. As far as I know, >> there is very little in Modula-3 that depends on the actual size >> in bits of INTEGERs and CARDINALs. It doesn't seem to me to make >> much sense to introduce types like Int32.T and Int64.T and then >> make the definition Int32.T = INTEGER (on one platform) and Int64.T >> = INTEGER (on another platform). I'm wondering if it would instead >> be possible to introduce a new group of types in the sense that >> Modula-3 now has integer types and floating-point types, and call >> these types "fixed width" or "specified width" types. Conversions >> between these types and INTEGER or CARDINAL would have to be done >> using functions (operators) that are the analogs of FLOAT, ROUND, >> etc. Standard arithmetic operators would be overloaded just like >> they are today for integers and floating-point numbers. Am I just >> duplicating someone else's proposal here? Perhaps this proposal >> doesn't address everything one might want to do with these extended- >> size types? >> >> Maybe I am just dreaming about getting Modula-3 running on a >> DECsystem-20 with 36-bit integers...with pickles that are >> interchangeable >> with i386 pickles, of course. >> >> What do people want to do with these extended-size types anyhow? >> It seems good to me that INTEGER is the largest type that I can >> expect my processor to calculate efficiently with. I would use >> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible >> and write my code to be flexible about the BYTE/BITSIZE... but OK, >> I can see the rationale for hiding all this in the compiler (and >> inlining everything) in the few cases where I might want four- >> function >> arithmetic on (specifically) 64- or 128-bit integers. >> >> Mika >> >> Darko writes: >>> Actually I stated the wrong reason for that one, it's really an >>> argument against mixed integer assignment. >>> >>> And saying that it looks right from the C/C++ point of view is >>> pretty >>> damning... >>> >>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote: >>> >>>> Mail from unsubscribed address forwarded to the list... >>>> ---------------------------- Original Message >>>> ---------------------------- >>>> Subject: Re: A nonnative 64-bit language proposal >>>> From: hendrik at topoi.pooq.com >>>> Date: Wed, October 25, 2006 14:22 >>>> To: m3devel at elegosoft.com >>>> ------------------------------------------------------------------- >>>> --- >>>> ---- >>>> >>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote: >>>>> >>>>> For your example to compute as an integer even if that >>>>> overflows and >>>>> it wouldn't as a longint seems right from my C/C++ point of view. >>>> >>>> I've always thought C/C++ were badly wrong on this one, even >>>> from their own archaic low-level machine-oriented viewpoint. >>>> Most computers have integer multiply instructions that return a >>>> double-length product. >>>> >>>> -- hendrik >>>> >>>> > From darko at darko.org Fri Jul 20 04:49:08 2007 From: darko at darko.org (Darko) Date: Fri, 20 Jul 2007 04:49:08 +0200 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FD59A.8020809@wichita.edu> <56185EC7-D47A-40B4-8990-76FB69314885@darko.org> Message-ID: <9A8114D3-DD14-459E-A423-DA1947A15235@darko.org> On the other side of the ledger, the fact that the following overflows is pretty unpleasant: CONST big = 2^32-1; VAR i: LONGINT; BEGIN i := big * big; On 19/07/2007, at 11:35 PM, Darko wrote: > I agree with you and I strongly agree with Tony's approach to the > implementation where the two integer types are not subtypes. > > The VAL usage would be a bit finicky given how often this would be > done in practice, something more concise (like INT and LONG) would > be better. > > > On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote: > >> In my original 64-bit proposal, I made INTEGER # LONGINT, and also >> the two >> types have no subtype relation (which, I think is what Antony is >> saying). >> It avoids having a lot of things happen implicitly from other >> rules in the >> language. >> >> But then I added a separate rule that these two types and their >> subranges >> are mutually assignable, subject to the existing assignability >> rules that >> now apply to a type and its subranges. Namely the RHS value must >> be in the >> range of the of the LHS type, which sometimes has to be checked at >> runtime. >> >> This allows assignment without explicit conversion, as well as >> many other >> things, for example, VALUE parameter passing, that require >> assignability. >> This is consistent with the existing rules for assignments involving >> different subranges. >> >> For explicit conversions (which are probably needed somewhere anyway, >> even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit >> the existing language well. For consistency, it seems good to allow >> ORD(LongIntArg), which is an alternative conversion in one direction. >> It may seem unnecessary, but it's not as useless as ORD(IntegerArg), >> which we already have. Actually, these extensions of VAL and ORD >> fall out of the existing definitions, when LONGINT is an ordinal >> type. >> >> Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >>> On 19/07/2007, at 10:26 PM, Tony Hosking wrote: >>>> This is a good question. I would assume that conversion must >>>> be explicit to fit with the M3 philosophy. It would make sense >>>> to have a conversion operation that performs the appropriate >>>> range check? Any ideas for a name for the operation. >>>> >>>> On Jul 19, 2007, at 4:23 PM, Darko wrote: >>>> >>>>> Have I missed something or is there no way to assign between >>>>> INTEGER and LONGINT? Is there an explicit conversion function >>>>> that I've overlooked? Would assignment be so bad here since >>>>> there would be an implicit range check, much like when you >>>>> assign between two overlapping subranges? In a sense these two >>>>> types are integer subranges of an abstract integer type >>>>> containing all integers. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > From mika at async.caltech.edu Fri Jul 20 09:16:09 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 20 Jul 2007 00:16:09 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Thu, 19 Jul 2007 11:27:48 EDT." Message-ID: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> Hi again Tony, I am wondering, is it at all possible you might have to compile the new compiler with itself to get it to generate the proper code? I was at first able to get Juno to crash: *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/JunoRT.m3", line 698 *** but after recompiling a second time, it no longer seems to do that. By the way, I am somewhat suspicious that this Juno crash has something to do with threading: if you look closely, that part of Juno has to do with thread switching into and out of the Juno-machine...which is why I was happy to see it disappear (however it did that). I still have a threading crash in mentor. I run "Wheeler" to get this one... gdb /usr/local/cm3/bin/mentor GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .......................................... done (gdb) run Starting program: /usr/local/cm3/bin/mentor Reading symbols for shared libraries .++++++++++++++++++++.++++++++++++++++++ done *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675 *** Program exited with code 01. (gdb) where No stack. (gdb) cvs status ./m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3 =================================================================== File: ThreadPThread.m3 Status: Up-to-date Working revision: 1.34 Repository revision: 1.34 /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v Commit Identifier: GYzMl9TO92Eakoqs Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) [QT:~/cm3] mika% OS: 10.4 / ppc (My 10.3 machine is in for service at the moment.) Also the Bresenham demo just dies for me now, but that could of course be a bug in mentor. It was working great the other day.. not sure what happened there. I really don't think it's my old system that's corrupting the new images, but I am *never* 100% certain of that. I found a very weird behavior with the build system, actually. I found that the not-yet-installed compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in /usr/local/cm3/bin, but *only* if that is in the shell PATH. Is that a known/desired behavior? It causes the brand new compiler to use the old cm3.cfg, and it does so quietly without any warnings or messages whatsoever. Changing your PATH makes it stop do that and instead crash, prompting me to put the cm3.cfg I want in the right place... Mika P.S. I agree with you that 8000 threads is ample and good going for pthreads. Tony Hosking writes: >Mika, > >I have diagnosed and fixed the problems you were seeing with thread >pausing and alerts. mentor no longer exhibits the bug you reported >and diagnosed. Thanks! I am starting to feel much more confident >about the threads subsystem now that I am able to run mentor's >functionality without problems on my Darwin 10.4.10 system using >pthreads. There are still the capacity problems (number of pthreads >beyond 8000) on Darwin, but that is a system issue not a problem with >the pthreads implementation. For large numbers of threads the user- >level implementation still seems the way to go. I want to update >that to use getcontext/setcontext ASAP so that it will function again >on platforms that have implemented secure (encrypting) versions of >setjmp/longjmp that prevent stack hacks like those used to implement >the current user-level threads system. Thanks again for your help, >and please let me know of any further issues. > >-- Tony > >On Jul 17, 2007, at 3:31 AM, Mika Nystrom wrote: > >> Hi Tony, >> >> I have a friend with a 10.4.10 system, >> >> Darwin QT.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 >> 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh >> powerpc >> >> I used your instructions again, installing from the CVS head. You're >> right, things are different on this OS! The programs that were >> taking 100% cpu (mine as well as the ones in the distribution) on >> my 10.3 system are not doing that on the the 10.4 system. ktok >> still crashes, now sometimes with an illegal instruction, sometimes >> at line 2310, as before. >> >> After some fiddling, during which mentor worked far better than on >> 10.3, I was able to get mentor to---as it appears---deadlock. The >> Bresenham demo seems to deadlock mentor pretty reliably for me. >> Here's a traceback from hitting ctrl-C after mentor has gone >> catatonic: >> >> (gdb) where >> #0 0x9002c3c8 in semaphore_wait_signal_trap () >> #1 0x90030eac in pthread_cond_wait () >> #2 0x01d2d83c in ThreadPThread__InnerWait (M3_AYIbX3_m=0x2860540, >> M3_Bl0jv4_c=0x2a43b24, M3_BXP32l_self=0x2860014) at >> ThreadPThread.m3:212 >> #3 0x01d2dc6c in Thread__Wait (M3_AYIbX3_m=0x2860540, >> M3_Bl0jv4_c=0x2a43b24) at ThreadPThread.m3:251 >> #4 0x018991d8 in Trestle__AwaitDelete (M3_BFdKo9_v=0x2a0a9cc) at >> Trestle.m3:884 >> #5 0x0120b058 in ZeusPanel__Interact (M3_Bd56fi_title=0x36ace0, >> M3_DYb95R_path=0x2863f94) at ZeusPanel.m3:477 >> #6 0x0028af0c in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:165 >> #7 0x01d16654 in RTLinker__RunMainBody (M3_DjPxE3_m=0x2b1428) at >> RTLinker.m3:399 >> #8 0x01d15418 in RTLinker__AddUnitI (M3_DjPxE3_m=0x2b1428) at >> RTLinker.m3:113 >> #9 0x01d15514 in RTLinker__AddUnit (M3_DjPxE5_b=0x28ae88) at >> RTLinker.m3:122 >> #10 0x00002a44 in main (argc=1, argv=0xbffffc98, envp=0xbffffca0) >> at _m3main.mc:4 >> >> My program that was having trouble with pickles now does the >> following. It is reading data out of a disk file that it has >> recently written using Pickle.Write. I'm afraid I can't give out >> the source code for this program, so I'll have to isolate a simpler >> case. Btw, this happens also with @M3nogc. No UNSAFE code of any >> kind involved here. Attempting to access the arguments of Text.Equal >> through gdb crashes gdb with a bus error. If someone has an idea >> (even a vague one) what might be the problem I could spend some >> time poking around the code... >> >> ((1)) FIXPersistentState.Init: initialized tbl backed by "states/ >> asdfw_25fwds.snt" >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 >> 0x900031c8 in strlen () >> (gdb) where >> #0 0x900031c8 in strlen () >> #1 0x01671c70 in Text8CString__GetInfo (M3_A8R5P5_t=0x1fb17f8, >> M3_BUgnwf_info=0xbfffe4bc) at Text8CString.m3:23 >> #2 0x0166dbd4 in Text__Equal (M3_Bd56fi_t=0x1fb17f8, >> M3_Bd56fi_u=0x1f9322c) at Text.m3:31 >> #3 0x003a8fd0 in FIXEngine__SanityCheckFields >> (M3_EdNxIG_t=0x1f953b0, M3_Ck0t2u_msg=0x1fb177c) at FIXEngine.m3:259 >> #4 0x003aad58 in FIXEngine__InitSession (M3_EdNxIG_t=0x1f953b0, >> M3_CVvbAZ_session=0x1f93290) at FIXEngine.m3:450 >> #5 0x003a9ad4 in FIXEngine__Init (M3_EdNxIG_t=0x1f953b0, >> M3_Cbj6ab_conn=0x1f95454, M3_CqtnCQ_mode=0 '\0', >> M3_Cwb5VA_heartBtInt=, M3_CVvbAZ_session=0x1f93290, >> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', >> M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=> 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=, >> M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Fri Jul 20 17:42:27 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 11:42:27 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> References: <200707200716.l6K7G9I4013857@camembert.async.caltech.edu> Message-ID: <066BF1FB-7815-4761-A04F-ED68A75564A5@cs.purdue.edu> 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=, M3_CVvbAZ_session=0x1f93290, >>> M3_DdEwXy_state=0x1f95000, M3_AicXUJ_unhandledMeansError=1 '\001', >>> M3_Cwb5VA_logonAttempts=, M3_Cwb5VA_minSid=>> 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=, >>> M3_Cwb5VA_minSid=) 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 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? From hosking at cs.purdue.edu Fri Jul 20 22:47:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 16:47:45 -0400 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FDFDE.9020201@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FDFDE.9020201@wichita.edu> Message-ID: <05CD4EBC-E1C6-4BB7-919C-8032B5265609@cs.purdue.edu> I think I am coming around to Rodney's position. We should consider INTEGER and LONGINT assignable under the current rules for subranges. Thus, INTEGER := LONGINT will cause a range check (and underlying conversion of the integer value from BITSIZE(LONGINT) to BITSIZE(INTEGER)), whereas LONGINT := INTEGER will need not check (though the conversion will be necessary to extend sign as expected). I believe this functionality can easily be implemented in the current compiler. Also, I am willing to allow indexing of arrays using LONGINT-based ordinals for the index type. The usual restrictions on array size will obtain, and zero-based array indexes will be computed into integer offsets. Thus, for an array indexed [minL..maxL] where minL and maxL have base type LONGINT, the offset will be computed as: index - minL and converted to an INTEGER value to index the array. Because of the sizing restriction, index - minL must be expressible as an INTEGER. Here are my revised notes: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longint.txt URL: -------------- next part -------------- On Jul 19, 2007, at 6:04 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> On Jul 19, 2007, at 4:33 PM, Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >> There is no implicit conversion for floats. The danger with >> implicit conversion for integers is that it would not be >> portable: you would get different behavior on different machines >> for the same code. Better to make the conversion explicit so >> that programmers are prepared for the range check to fail. > > But is this argument any stronger for requiring explicit conversions > for INTEGER/LONGINT assignments than for assigning to subranges? > Many assignments in the language now, without any type conversion, > admit the possibility of RT range errors. And these can be dependent > on the size of INTEGER too. Consider: > > VAR V : [ 0 .. 65535 ] ; > VAR I : CARDINAL ; > ... > V := I DIV 2 ; > > I think for portability, the principle that the static semantics > should be > the same for all sizes of INTEGER (and LONGINT too) is as much as > we can > hope for. Certainly, there are already countless ways the integer > size can > change the dynamic semantics of a program. > > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From mika at async.caltech.edu Sun Jul 22 14:12:07 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 22 Jul 2007 05:12:07 -0700 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: Your message of "Fri, 20 Jul 2007 11:42:27 EDT." <066BF1FB-7815-4761-A04F-ED68A75564A5@cs.purdue.edu> Message-ID: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Tony Hosking writes: ... >> 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 *obsessively* clean my directories between builds! I have double- and triple-checked that nothing in the source tree is left in object form after doing do-cm3-std.sh realclean do-cm3-core.sh realclean Yet, this happens. My best guess is that somehow, old objects (from /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. Surely that's not supposed to happen? Why does it happen to me and apparently not to you? I follow your directions exactly and always start from an absolutely clean system (on Mac I don't even have PM3 installed, so there's no Modula-3 at all before I start following the instructions). >> I still have a threading crash in mentor. I run "Wheeler" to get this >> one... >> ... >> >> *** >> *** 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. Debugging this a bit further, I think I'm just running out of stack space. You are saying that this call can fail because of too small a requested stack space, too? It might be nice to have some sort of error message here instead of just an assert failure... How big is your stack limit on your mac? On mine it's 64 megabytes, and when I added some printing: RTIO.PutText("Upthread.attr_getstacksize returned bytes="); RTIO.PutInt(bytes); RTIO.PutText(" defaultStackSize="); RTIO.PutInt(defaultStackSize); RTIO.PutChar('\n'); bytes := MAX(bytes, size * ADRSIZE(Word.T)); WITH r = Upthread.attr_setstacksize(attr, bytes) DO IF r # 0 THEN RTIO.PutText("Upthread.attr_setstacksize failed, size="); ELSE RTIO.PutText("Upthread.attr_setstacksize succeeded, size="); END; RTIO.PutInt(size); RTIO.PutText(" bytes="); RTIO.PutInt(bytes); RTIO.PutChar('\n'); <*ASSERT r=0*> END; RTIO.Flush(); I found the following: (running Wheeler) ... lots of times ... Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 Upthread.attr_getstacksize returned bytes=524288 defaultStackSize=79632 Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 Upthread.attr_getstacksize returned bytes=524288 defaultStackSize=79632 Upthread.attr_setstacksize failed, size=637056 bytes=2548224 *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 *** Program exited with code 01. It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize for another 64 kilowords , and WheelerCompressObliqView.m3 requests 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads and I just run out of stack space. (I am assuming that pthreads allocates stacks in the 'stack' segment of the process...) Attempting to fix the bug in mentor makes it run out of stack space, looks like it's some recursive descent parser... Maybe this demo just won't run on my computer. >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 was able to get it to run again. And deadlock again. And run again... it's definitely something intermittent. I think it happens right when it attempts to start the threads, not afterwards. And when you ctrl-C it, all you get is that it's stopped in Trestle__AwaitDelete (I already sent this one). > >> 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. > Here's what I'm doing... I install cm3-5.4.0 from the elegosoft site using that package's cminstall. This installs a cm3.cfg. Then I follow your directions for bootstrapping from the CVS head. At some point, those directions say to switch from using the original compiler to the newly compiled compiler. Now, when you switch to the newly compiled compiler, the only cm3.cfg in the system is the one from the bootstrappING compiler, that is, the 5.4.0 release cm3.cfg. What happens is the following: 1. If my shell PATH includes the path to the old cm3, the new compiler (silently) finds the old cm3.cfg and uses it. 2. If my shell PATH does not include the path to the old cm3, the new compiler does not find the old cm3.cfg. This behavior will easily trip someone up who's trying to bootstrap cm3, because I don't think any of the scripts (or bootstrapping directions) do anything whatever to make sure that the new compiler gets a new cm3.cfg. What I've taken to doing is taking cm3 out of my PATH permanently so that I always have to type the full path. That way I can't get a compiler-cfg mismatch, because the new compiler will refuse to work until I have provided it with a new cm3.cfg. I've been doing this for the last several bootstraps. Mika From hosking at cs.purdue.edu Sun Jul 22 17:16:10 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 22 Jul 2007 11:16:10 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> References: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: Hi Mika, Thanks for all of your useful feedback. My replies below... On Jul 22, 2007, at 8:12 AM, Mika Nystrom wrote: > > Tony Hosking writes: > ... >>> 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 *obsessively* clean my directories between builds! I have double- > and triple-checked that nothing in the source tree is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, old objects (from > /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. > Surely that's not supposed to happen? Why does it happen to me and > apparently not to you? I follow your directions exactly and always > start from an absolutely clean system (on Mac I don't even have PM3 > installed, so there's no Modula-3 at all before I start following > the instructions). I'm not trying to imply that you are doing anything wrong -- just wanting to make sure that we isolate the problem carefully in order to diagnose it. As I have mentioned in the past, I hand-build my bootstrap compilers, avoiding using the scripts, since the order of package builds can vary depending on which parts of the runtime and compiler subsystems have been changed. I only use the do-cm3-std.sh script once I am sure I have a functional compiler. Have you managed to reproduce the error from before? > > >>> I still have a threading crash in mentor. I run "Wheeler" to get >>> this >>> one... >>> > ... >>> >>> *** >>> *** 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. > > Debugging this a bit further, I think I'm just running out of stack > space. You are saying that this call can fail because of too small > a requested stack space, too? It might be nice to have some sort > of error message here instead of just an assert failure... Yes, that's why I think it may be better to try pthread_attr_setstacksize without checking the return value. Better to ignore a bad sized closure's request for a particular size than to crash and burn. > > How big is your stack limit on your mac? On mine it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize succeeded, > size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize > for another 64 kilowords , and WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads > and I just run out of stack space. (I am assuming that pthreads > allocates stacks in the 'stack' segment of the process...) Yes, that is probably the case. > > Attempting to fix the bug in mentor makes it run out of stack space, > looks like it's some recursive descent parser... Maybe this demo > just won't run on my computer. This is troubling. Perhaps we should more explicitly allocate stacks from the heap so as to avoid this issue. I can look into this. > >> 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 was able to get it to run again. And deadlock again. And run > again... it's definitely something intermittent. I think it happens > right when it attempts to start the threads, not afterwards. > > And when you ctrl-C it, all you get is that it's stopped > in Trestle__AwaitDelete (I already sent this one). Hmm. More food for thought. >>> 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. >> > > Here's what I'm doing... > > I install cm3-5.4.0 from the elegosoft site using that package's > cminstall. This installs a cm3.cfg. > > Then I follow your directions for bootstrapping from the CVS head. > At some point, those directions say to switch from using the original > compiler to the newly compiled compiler. > > Now, when you switch to the newly compiled compiler, the only cm3.cfg > in the system is the one from the bootstrappING compiler, that is, the > 5.4.0 release cm3.cfg. What happens is the following: > > 1. If my shell PATH includes the path to the old cm3, the new compiler > (silently) finds the old cm3.cfg and uses it. > > 2. If my shell PATH does not include the path to the old cm3, the new > compiler does not find the old cm3.cfg. > > This behavior will easily trip someone up who's trying to bootstrap > cm3, because I don't think any of the scripts (or bootstrapping > directions) do anything whatever to make sure that the new compiler > gets a new cm3.cfg. What I've taken to doing is taking cm3 out of > my PATH permanently so that I always have to type the full path. > That way I can't get a compiler-cfg mismatch, because the new compiler > will refuse to work until I have provided it with a new cm3.cfg. > I've been doing this for the last several bootstraps. Yes, I think this is a problem. I have never used the CM3 install scripts, since I am in bootstrapping mode almost all the time as part of the development cycle, so I am always using the same cm3.cfg. I think your strategy is a good one for bootstrapping with a cminstall system present. > > > Mika From dabenavidesd at yahoo.es Sun Jul 22 21:31:42 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 22 Jul 2007 21:31:42 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: <487036.69680.qm@web27110.mail.ukl.yahoo.com> Hi: What I have saw of the two step boostrapping process is that cm3 executable looks in its own directory for cm3.cfg, so I have made a copy from /usr/local/cm3/bin to /usr/local/cm3/pkg/cm3/LINUXLIBC6 Another thing is that do-cm3-std.sh realclean, doesnt clean some m3core parts, some yes. Thanks --- Mika Nystrom wrote: > > Tony Hosking writes: > ... > >> 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 *obsessively* clean my directories between builds! > I have double- > and triple-checked that nothing in the source tree > is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, > old objects (from > /usr/local/cm3/pkg?) are "leaking" through the > bootstrapping process. > Surely that's not supposed to happen? Why does it > happen to me and > apparently not to you? I follow your directions > exactly and always > start from an absolutely clean system (on Mac I > don't even have PM3 > installed, so there's no Modula-3 at all before I > start following > the instructions). > > > >> I still have a threading crash in mentor. I run > "Wheeler" to get this > >> one... > >> > ... > >> > >> *** > >> *** 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. > > Debugging this a bit further, I think I'm just > running out of stack > space. You are saying that this call can fail > because of too small > a requested stack space, too? It might be nice to > have some sort > of error message here instead of just an assert > failure... > > How big is your stack limit on your mac? On mine > it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize > returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, > bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize > failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize > succeeded, size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 > bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 > bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 > bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls > IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls > IncDefaultStackSize > for another 64 kilowords , and > WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of > those threads > and I just run out of stack space. (I am assuming > that pthreads > allocates stacks in the 'stack' segment of the > process...) > > Attempting to fix the bug in mentor makes it run out > of stack space, > looks like it's some recursive descent parser... > Maybe this demo > just won't run on my computer. > > >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 was able to get it to run again. And deadlock > again. And run > again... it's definitely something intermittent. I > think it happens > right when it attempts to start the threads, not > afterwards. > > And when you ctrl-C it, all you get is that it's > stopped > in Trestle__AwaitDelete (I already sent this one). > > > > >> 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, > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Mon Jul 23 09:29:41 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Jul 2007 09:29:41 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <487036.69680.qm@web27110.mail.ukl.yahoo.com> Message-ID: <412757.94770.qm@web27109.mail.ukl.yahoo.com> Hi, Actually the existing directories on m3-sys after execution of scripts/do-cm3-std.sh buildship: m3linker m3front cm3 On the These packages are not listed when that script inits I guess these packages are not necessary when boostrapping cm3 without steps. Executing scripts/do-cm3-core.sh realclean does that cleans. Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > What I have saw of the two step boostrapping process > is that cm3 executable looks in its own directory > for > cm3.cfg, so I have made a copy from > /usr/local/cm3/bin > to /usr/local/cm3/pkg/cm3/LINUXLIBC6 > > Another thing is that do-cm3-std.sh realclean, > doesnt > clean some m3core parts, some yes. > > > Thanks > > --- Mika Nystrom wrote: > > > > > Tony Hosking writes: > > ... > > >> 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 *obsessively* clean my directories between > builds! > > I have double- > > and triple-checked that nothing in the source tree > > is left in object > > form after doing > > > > do-cm3-std.sh realclean > > do-cm3-core.sh realclean > > > > Yet, this happens. My best guess is that somehow, > > old objects (from > > /usr/local/cm3/pkg?) are "leaking" through the > > bootstrapping process. > > Surely that's not supposed to happen? Why does it > > happen to me and > > apparently not to you? I follow your directions > > exactly and always > > start from an absolutely clean system (on Mac I > > don't even have PM3 > > installed, so there's no Modula-3 at all before I > > start following > > the instructions). > > > > > > >> I still have a threading crash in mentor. I > run > > "Wheeler" to get this > > >> one... > > >> > > ... > > >> > > >> *** > > >> *** 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. > > > > Debugging this a bit further, I think I'm just > > running out of stack > > space. You are saying that this call can fail > > because of too small > > a requested stack space, too? It might be nice to > > have some sort > > of error message here instead of just an assert > > failure... > > > > How big is your stack limit on your mac? On mine > > it's 64 megabytes, > > and when I added some printing: > > > > RTIO.PutText("Upthread.attr_getstacksize > > returned bytes="); > > RTIO.PutInt(bytes); > > RTIO.PutText(" defaultStackSize="); > > RTIO.PutInt(defaultStackSize); > > RTIO.PutChar('\n'); > > > > bytes := MAX(bytes, size * > ADRSIZE(Word.T)); > > WITH r = Upthread.attr_setstacksize(attr, > > bytes) DO > > IF r # 0 THEN > > > RTIO.PutText("Upthread.attr_setstacksize > > failed, size="); > > ELSE > > > RTIO.PutText("Upthread.attr_setstacksize > > succeeded, size="); > > END; > > RTIO.PutInt(size); > > RTIO.PutText(" bytes="); > > RTIO.PutInt(bytes); > > RTIO.PutChar('\n'); > > <*ASSERT r=0*> > > END; > > RTIO.Flush(); > > > > I found the following: > > > > (running Wheeler) > > > > ... lots of times ... > > Upthread.attr_setstacksize succeeded, size=79632 > > bytes=524288 > > Upthread.attr_getstacksize returned bytes=524288 > > defaultStackSize=79632 > > Upthread.attr_setstacksize succeeded, size=79632 > > bytes=524288 > > Upthread.attr_getstacksize returned bytes=524288 > > defaultStackSize=79632 > > Upthread.attr_setstacksize failed, size=637056 > > bytes=2548224 > > > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file > > "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > > *** > > > > > > Program exited with code 01. > > > > It's really a bug in mentor. Zeus.m3:499 calls > > IncDefaultStackSize > > to request another 10 kilowords, Obliq.m3:32 calls > > IncDefaultStackSize > > for another 64 kilowords , and > > WheelerCompressObliqView.m3 requests > > 8*GetDefaultStackSize in a SizedClosure. A bunch > of > > those threads > > and I just run out of stack space. (I am assuming > > that pthreads > > allocates stacks in the 'stack' segment of the > > process...) > > > > Attempting to fix the bug in mentor makes it run > out > > of stack space, > > looks like it's some recursive descent parser... > > Maybe this demo > > just won't run on my computer. > > > > >Weird, I was running Bresenham just fine > yesterday > > after the fix I > > >checked in. Sounds like you may have some stale > > object files lying > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From wagner at elegosoft.com Mon Jul 23 12:55:22 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Jul 2007 12:55:22 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <412757.94770.qm@web27109.mail.ukl.yahoo.com> References: <412757.94770.qm@web27109.mail.ukl.yahoo.com> Message-ID: <37913.194.138.127.36.1185188122.squirrel@mail.elegosoft.com> do-cm3-std.sh is the script that builds the complete set of usable M3 application packages after an initial CM3 installation. It has no connection to compiler bootstrapping at all. do-cm3-core.sh is a script that can be used to build a basic system without any demos or large applications, but including the compiler itself. It can usually not be used for bootstrapping the compiler either (at least on its own, as changes in supported platforms or other core units may require more elaborate build and ship schemes). The scripts were intended for the M3 end user and not for the rather special situation of language and runtime development of CM3 itself. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Mon Jul 23 15:43:37 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 23 Jul 2007 15:43:37 +0200 (CEST) Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <37913.194.138.127.36.1185188122.squirrel@mail.elegosoft.com> Message-ID: <502092.9992.qm@web27110.mail.ukl.yahoo.com> Hi, actually I meant when doing the two step bootstrapping process the existing directories (TARGET) on m3-sys after execution of scripts/do-cm3-std.sh realclean are: m3linker m3front cm3 These packages are not listed when that script inits I guess these packages are not necessary when boostrapping cm3 without steps. Executing scripts/do-cm3-core.sh realclean does that cleans. Thanks --- Olaf Wagner wrote: > do-cm3-std.sh is the script that builds the complete > set of usable > M3 application packages after an initial CM3 > installation. It has > no connection to compiler bootstrapping at all. > > do-cm3-core.sh is a script that can be used to build > a basic system > without any demos or large applications, but > including the compiler > itself. It can usually not be used for > bootstrapping the compiler > either (at least on its own, as changes in > supported platforms or > other core units may require more elaborate build > and ship schemes). > > The scripts were intended for the M3 end user and > not for the rather > special situation of language and runtime > development of CM3 itself. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 > | USt-IdNr: DE163214194 > > ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From mika at async.caltech.edu Tue Jul 24 15:54:28 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 24 Jul 2007 06:54:28 -0700 Subject: [M3devel] Question about TEXTs under CM3 Message-ID: <200707241354.l6ODsSh6032994@camembert.async.caltech.edu> Hello everyone, Here's a random question that hopefully someone can answer... Is it true that certain TEXTs can't be Pickled under CM3? Unless there's some magic I don't understand going on, I am thinking that would be the implication of: UNSAFE INTERFACE Text8CString; ... TYPE T <: Public; Public = TEXT OBJECT str: Ctypes.char_star; END; (* The array contains the characters of the text followed by a '\000'. *) ... I hope someone can set me straight and tell me that no, the situation isn't as dire as that---some clever thing somewhere makes it possible to Pickle all objects of type TEXT... Mika From mika at async.caltech.edu Thu Jul 26 14:40:29 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Jul 2007 05:40:29 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Tue, 24 Jul 2007 06:54:28 PDT." <200707241354.l6ODsSh6032994@camembert.async.caltech.edu> Message-ID: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Ok, I am about to answer my own email. Here's a little program I wrote: MODULE Main; IMPORT Pickle, IO, Params, TextWr, TextRd; VAR wr := NEW(TextWr.T).init(); toPickle := "pickle this"; BEGIN IF Params.Count > 1 THEN toPickle := Params.Get(1) END; Pickle.Write(wr,toPickle); IO.Put("pickled \""&toPickle&"\"\n"); IO.Put("read back \""& Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) &"\"\n"); END Main. === On FreeBSD4 with my ancient, creaky PM3: (64)trs80:~/ptest/src>../FreeBSD4/pickleit pickled "pickle this" read back "pickle this" (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that pickled "pickle that" read back "pickle that" === On PPC_DARWIN with the latest CM3: [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickled "pickle this" read back "pickle this" [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that pickled "pickle that" *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** Abort === On FreeBSD4 with the latest CM3: (73)rover:~/ptest/src>../FreeBSD4/pickleit pickled "pickle this" read back "pickle this" (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that pickled "pickle that" *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** Abort ============ Diagnosis: The code I mentioned in a previous email declares a Text8CString.T to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere in the system, Ctypes.char_star is specifically declared to be an "UNTRACED REF Ctypes.char". According to the specification of Pickle, an UNTRACED REF is pickled as NIL. Generally speaking, you don't see many Text8CString.Ts in the system. This one comes in via Params.Get, which in turn calls RTArgs.GetArg, which in turn calls M3toC.StoT. StoT is generally not something you want to call, but it's supposed to be OK here because you're just passing around argv, which won't change. Generally speaking, it ought to be OK to use to convert C strings whose addresses aren't going to change during the lifetime of the program. I think it is *totally unacceptable* that Params.Get returns a "poisoned" TEXT. There is absolutely nothing in any of the interfaces that warns of this fact, and it is surprising to say the least. There is also no simple way of "copying" TEXTs, as it shouldn't ever be required! Finally, there's no way of checking whether a TEXT is a Text8CString.T without importing Text8CString, which is an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! What does baffle me a bit is that the code works on the old PM3. It uses the old TextF, which declares TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; The old (from PM3, I think it's 1.1.15) M3toC has: PROCEDURE StoT (s: Ctypes.char_star): TEXT = VAR t := NEW (M3TextWithHeader); BEGIN t.header.typecode := RT0.TextTypecode; t.body.chars := LOOPHOLE (s, ADDRESS); t.body.length := 1 + Cstring.strlen (s); RETURN LOOPHOLE (ADR (t.body), TEXT); END StoT; I'm not entirely sure why the old code works---why isn't the M3TextWithHeader garbage-collected? The pickler doesn't seem to know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. In fact the pickler doesn't seem to know anything about TEXTs at all. I see several possible ways of solving the problem. One is to permit M3toC.StoT to remain broken (since M3toC is an UNSAFE interface, there's no "legal" reason not to do that) and make sure Params.Get (and everything else that could remotely be called "standard") doesn't use M3toC.StoT---oh and to leave some very prominent warning signs, both in M3toC and Text8CString that "here be demons". Another is to revert to the SRC method of LOOPHOLEing the C strings. I never liked the CM3 TEXTs, and I like them even less now; I disliked them from the start because they broke pickle compatibility with SRC M3, and now I find that they aren't even compatible with themselves. Modula-3's strengths have always been its utter simplicity and bullet-proof reliability. This stuff, where some objects are more "serializable" than others, reminds me of Java! Does anyone have an opinion as to how this problem ought to be solved? Mika Mika Nystrom writes: >Hello everyone, > >Here's a random question that hopefully someone can answer... > >Is it true that certain TEXTs can't be Pickled under CM3? > >Unless there's some magic I don't understand going on, I am thinking >that would be the implication of: > >UNSAFE INTERFACE Text8CString; >... >TYPE > T <: Public; > Public = TEXT OBJECT > str: Ctypes.char_star; > END; > (* The array contains the characters of the text followed by a '\000'. *) >... > >I hope someone can set me straight and tell me that no, the situation >isn't as dire as that---some clever thing somewhere makes it possible >to Pickle all objects of type TEXT... > > Mika From hosking at cs.purdue.edu Thu Jul 26 15:47:46 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 09:47:46 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Message-ID: Looks like we need to fix M3toC.StoT so that it works the same as old PM3. The old code works because it constructs a text *in* the heap as an ARRAY OF CHAR, that just happens to have its payload (the array contents) outside the heap. (Arrays in M3 contain a reference to their data). We can play the same trick for Text8CString and get things to work properly for you. I will make this fix and check it in. On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: > Ok, I am about to answer my own email. Here's a little program I > wrote: > > MODULE Main; > IMPORT Pickle, IO, Params, TextWr, TextRd; > > VAR wr := NEW(TextWr.T).init(); > toPickle := "pickle this"; > BEGIN > IF Params.Count > 1 THEN toPickle := Params.Get(1) END; > > Pickle.Write(wr,toPickle); > > IO.Put("pickled \""&toPickle&"\"\n"); > IO.Put("read back \""& > Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) > &"\"\n"); > END Main. > > === On FreeBSD4 with my ancient, creaky PM3: > > (64)trs80:~/ptest/src>../FreeBSD4/pickleit > pickled "pickle this" > read back "pickle this" > (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that > pickled "pickle that" > read back "pickle that" > > === On PPC_DARWIN with the latest CM3: > > [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit > pickled "pickle this" > read back "pickle this" > [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that > pickled "pickle that" > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** > > Abort > > === On FreeBSD4 with the latest CM3: > > (73)rover:~/ptest/src>../FreeBSD4/pickleit > pickled "pickle this" > read back "pickle this" > (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that > pickled "pickle that" > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** > > Abort > > ============ > > Diagnosis: > > The code I mentioned in a previous email declares a Text8CString.T > to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere > in the system, Ctypes.char_star is specifically declared to be an > "UNTRACED REF Ctypes.char". According to the specification of > Pickle, an UNTRACED REF is pickled as NIL. > > Generally speaking, you don't see many Text8CString.Ts in the system. > This one comes in via Params.Get, which in turn calls RTArgs.GetArg, > which in turn calls M3toC.StoT. > > StoT is generally not something you want to call, but it's supposed > to be OK here because you're just passing around argv, which won't > change. Generally speaking, it ought to be OK to use to convert > C strings whose addresses aren't going to change during the lifetime > of the program. > > I think it is *totally unacceptable* that Params.Get returns a > "poisoned" TEXT. There is absolutely nothing in any of the interfaces > that warns of this fact, and it is surprising to say the least. > There is also no simple way of "copying" TEXTs, as it shouldn't > ever be required! Finally, there's no way of checking whether a > TEXT is a Text8CString.T without importing Text8CString, which is > an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! > > What does baffle me a bit is that the code works on the old PM3. > It uses the old TextF, which declares > > TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; > > The old (from PM3, I think it's 1.1.15) M3toC has: > > PROCEDURE StoT (s: Ctypes.char_star): TEXT = > VAR t := NEW (M3TextWithHeader); > BEGIN > t.header.typecode := RT0.TextTypecode; > t.body.chars := LOOPHOLE (s, ADDRESS); > t.body.length := 1 + Cstring.strlen (s); > RETURN LOOPHOLE (ADR (t.body), TEXT); > END StoT; > > I'm not entirely sure why the old code works---why isn't the > M3TextWithHeader garbage-collected? The pickler doesn't seem to > know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. > In fact the pickler doesn't seem to know anything about TEXTs > at all. > > I see several possible ways of solving the problem. One is to > permit M3toC.StoT to remain broken (since M3toC is an UNSAFE > interface, there's no "legal" reason not to do that) and make sure > Params.Get (and everything else that could remotely be called > "standard") doesn't use M3toC.StoT---oh and to leave some very > prominent warning signs, both in M3toC and Text8CString that "here > be demons". Another is to revert to the SRC method of LOOPHOLEing > the C strings. I never liked the CM3 TEXTs, and I like them even > less now; I disliked them from the start because they broke pickle > compatibility with SRC M3, and now I find that they aren't even > compatible with themselves. > > Modula-3's strengths have always been its utter simplicity > and bullet-proof reliability. This stuff, where some objects are > more "serializable" than others, reminds me of Java! > > Does anyone have an opinion as to how this problem ought to be > solved? > > Mika > > Mika Nystrom writes: >> Hello everyone, >> >> Here's a random question that hopefully someone can answer... >> >> Is it true that certain TEXTs can't be Pickled under CM3? >> >> Unless there's some magic I don't understand going on, I am thinking >> that would be the implication of: >> >> UNSAFE INTERFACE Text8CString; >> ... >> TYPE >> T <: Public; >> Public = TEXT OBJECT >> str: Ctypes.char_star; >> END; >> (* The array contains the characters of the text followed by a >> '\000'. *) >> ... >> >> I hope someone can set me straight and tell me that no, the situation >> isn't as dire as that---some clever thing somewhere makes it possible >> to Pickle all objects of type TEXT... >> >> Mika From mika at async.caltech.edu Thu Jul 26 16:04:07 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 26 Jul 2007 07:04:07 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Thu, 26 Jul 2007 09:47:46 EDT." Message-ID: <200707261404.l6QE47LU009706@camembert.async.caltech.edu> Tony Hosking writes: >Looks like we need to fix M3toC.StoT so that it works the same as old >PM3. The old code works because it constructs a text *in* the heap >as an ARRAY OF CHAR, that just happens to have its payload (the array >contents) outside the heap. (Arrays in M3 contain a reference to >their data). We can play the same trick for Text8CString and get >things to work properly for you. I will make this fix and check it in. > > >On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: ... >> Does anyone have an opinion as to how this problem ought to be >> solved? >> ... that's more than an opinion, but I'll happily accept it! :-) Mika From hosking at cs.purdue.edu Thu Jul 26 17:26:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 11:26:31 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> Message-ID: <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> On closer inspection, it is even messier than that. In the old PM3 the text that is constructed is allocated in UNTRACED storage (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be GC'd, and looks (to the GC) like an (old-style) text literal allocated outside the heap. It is harder for us to fake up a text literal like this with the new TEXT setup since we'd need to allocate, copy, and loophole something that looks like a text literal (an object) in the untraced heap. The best alternative is to fix the pickler with a special that handles Text8Cstrings. I think this is the cleanest approach. Mika, please try the following program, which adds a special for Text8CString. I will put this code into the builtin specials for pickles. On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: > Looks like we need to fix M3toC.StoT so that it works the same as > old PM3. The old code works because it constructs a text *in* the > heap as an ARRAY OF CHAR, that just happens to have its payload > (the array contents) outside the heap. (Arrays in M3 contain a > reference to their data). We can play the same trick for > Text8CString and get things to work properly for you. I will make > this fix and check it in. > > > On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: > >> Ok, I am about to answer my own email. Here's a little program I >> wrote: >> >> MODULE Main; >> IMPORT Pickle, IO, Params, TextWr, TextRd; >> >> VAR wr := NEW(TextWr.T).init(); >> toPickle := "pickle this"; >> BEGIN >> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >> >> Pickle.Write(wr,toPickle); >> >> IO.Put("pickled \""&toPickle&"\"\n"); >> IO.Put("read back \""& >> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >> &"\"\n"); >> END Main. >> >> === On FreeBSD4 with my ancient, creaky PM3: >> >> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >> pickled "pickle this" >> read back "pickle this" >> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >> pickled "pickle that" >> read back "pickle that" >> >> === On PPC_DARWIN with the latest CM3: >> >> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >> pickled "pickle this" >> read back "pickle this" >> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >> pickled "pickle that" >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** >> >> Abort >> >> === On FreeBSD4 with the latest CM3: >> >> (73)rover:~/ptest/src>../FreeBSD4/pickleit >> pickled "pickle this" >> read back "pickle this" >> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >> pickled "pickle that" >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** >> >> Abort >> >> ============ >> >> Diagnosis: >> >> The code I mentioned in a previous email declares a Text8CString.T >> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >> in the system, Ctypes.char_star is specifically declared to be an >> "UNTRACED REF Ctypes.char". According to the specification of >> Pickle, an UNTRACED REF is pickled as NIL. >> >> Generally speaking, you don't see many Text8CString.Ts in the system. >> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >> which in turn calls M3toC.StoT. >> >> StoT is generally not something you want to call, but it's supposed >> to be OK here because you're just passing around argv, which won't >> change. Generally speaking, it ought to be OK to use to convert >> C strings whose addresses aren't going to change during the lifetime >> of the program. >> >> I think it is *totally unacceptable* that Params.Get returns a >> "poisoned" TEXT. There is absolutely nothing in any of the >> interfaces >> that warns of this fact, and it is surprising to say the least. >> There is also no simple way of "copying" TEXTs, as it shouldn't >> ever be required! Finally, there's no way of checking whether a >> TEXT is a Text8CString.T without importing Text8CString, which is >> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >> >> What does baffle me a bit is that the code works on the old PM3. >> It uses the old TextF, which declares >> >> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >> >> The old (from PM3, I think it's 1.1.15) M3toC has: >> >> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >> VAR t := NEW (M3TextWithHeader); >> BEGIN >> t.header.typecode := RT0.TextTypecode; >> t.body.chars := LOOPHOLE (s, ADDRESS); >> t.body.length := 1 + Cstring.strlen (s); >> RETURN LOOPHOLE (ADR (t.body), TEXT); >> END StoT; >> >> I'm not entirely sure why the old code works---why isn't the >> M3TextWithHeader garbage-collected? The pickler doesn't seem to >> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >> In fact the pickler doesn't seem to know anything about TEXTs >> at all. >> >> I see several possible ways of solving the problem. One is to >> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >> interface, there's no "legal" reason not to do that) and make sure >> Params.Get (and everything else that could remotely be called >> "standard") doesn't use M3toC.StoT---oh and to leave some very >> prominent warning signs, both in M3toC and Text8CString that "here >> be demons". Another is to revert to the SRC method of LOOPHOLEing >> the C strings. I never liked the CM3 TEXTs, and I like them even >> less now; I disliked them from the start because they broke pickle >> compatibility with SRC M3, and now I find that they aren't even >> compatible with themselves. >> >> Modula-3's strengths have always been its utter simplicity >> and bullet-proof reliability. This stuff, where some objects are >> more "serializable" than others, reminds me of Java! >> >> Does anyone have an opinion as to how this problem ought to be >> solved? >> >> Mika >> >> Mika Nystrom writes: >>> Hello everyone, >>> >>> Here's a random question that hopefully someone can answer... >>> >>> Is it true that certain TEXTs can't be Pickled under CM3? >>> >>> Unless there's some magic I don't understand going on, I am thinking >>> that would be the implication of: >>> >>> UNSAFE INTERFACE Text8CString; >>> ... >>> TYPE >>> T <: Public; >>> Public = TEXT OBJECT >>> str: Ctypes.char_star; >>> END; >>> (* The array contains the characters of the text followed by a >>> '\000'. *) >>> ... >>> >>> I hope someone can set me straight and tell me that no, the >>> situation >>> isn't as dire as that---some clever thing somewhere makes it >>> possible >>> to Pickle all objects of type TEXT... >>> >>> Mika From hosking at cs.purdue.edu Thu Jul 26 18:02:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 26 Jul 2007 12:02:19 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> References: <200707261240.l6QCeTjB007238@camembert.async.caltech.edu> <36349556-F04F-4530-9F18-65322B9D104C@cs.purdue.edu> Message-ID: I'm about to check in the fix. I have tested this with your example program and things work fine. On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: > On closer inspection, it is even messier than that. In the old PM3 > the text that is constructed is allocated in UNTRACED storage > (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be > GC'd, and looks (to the GC) like an (old-style) text literal > allocated outside the heap. It is harder for us to fake up a text > literal like this with the new TEXT setup since we'd need to > allocate, copy, and loophole something that looks like a text > literal (an object) in the untraced heap. The best alternative is > to fix the pickler with a special that handles Text8Cstrings. I > think this is the cleanest approach. Mika, please try the > following program, which adds a special for Text8CString. I will > put this code into the builtin specials for pickles. > > On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: > >> Looks like we need to fix M3toC.StoT so that it works the same as >> old PM3. The old code works because it constructs a text *in* the >> heap as an ARRAY OF CHAR, that just happens to have its payload >> (the array contents) outside the heap. (Arrays in M3 contain a >> reference to their data). We can play the same trick for >> Text8CString and get things to work properly for you. I will make >> this fix and check it in. >> >> >> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >> >>> Ok, I am about to answer my own email. Here's a little program I >>> wrote: >>> >>> MODULE Main; >>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>> >>> VAR wr := NEW(TextWr.T).init(); >>> toPickle := "pickle this"; >>> BEGIN >>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>> >>> Pickle.Write(wr,toPickle); >>> >>> IO.Put("pickled \""&toPickle&"\"\n"); >>> IO.Put("read back \""& >>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>> &"\"\n"); >>> END Main. >>> >>> === On FreeBSD4 with my ancient, creaky PM3: >>> >>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>> pickled "pickle that" >>> read back "pickle that" >>> >>> === On PPC_DARWIN with the latest CM3: >>> >>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>> pickled "pickle that" >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** >>> >>> Abort >>> >>> === On FreeBSD4 with the latest CM3: >>> >>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>> pickled "pickle this" >>> read back "pickle this" >>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>> pickled "pickle that" >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** >>> >>> Abort >>> >>> ============ >>> >>> Diagnosis: >>> >>> The code I mentioned in a previous email declares a Text8CString.T >>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>> in the system, Ctypes.char_star is specifically declared to be an >>> "UNTRACED REF Ctypes.char". According to the specification of >>> Pickle, an UNTRACED REF is pickled as NIL. >>> >>> Generally speaking, you don't see many Text8CString.Ts in the >>> system. >>> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >>> which in turn calls M3toC.StoT. >>> >>> StoT is generally not something you want to call, but it's supposed >>> to be OK here because you're just passing around argv, which won't >>> change. Generally speaking, it ought to be OK to use to convert >>> C strings whose addresses aren't going to change during the lifetime >>> of the program. >>> >>> I think it is *totally unacceptable* that Params.Get returns a >>> "poisoned" TEXT. There is absolutely nothing in any of the >>> interfaces >>> that warns of this fact, and it is surprising to say the least. >>> There is also no simple way of "copying" TEXTs, as it shouldn't >>> ever be required! Finally, there's no way of checking whether a >>> TEXT is a Text8CString.T without importing Text8CString, which is >>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>> >>> What does baffle me a bit is that the code works on the old PM3. >>> It uses the old TextF, which declares >>> >>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>> >>> The old (from PM3, I think it's 1.1.15) M3toC has: >>> >>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>> VAR t := NEW (M3TextWithHeader); >>> BEGIN >>> t.header.typecode := RT0.TextTypecode; >>> t.body.chars := LOOPHOLE (s, ADDRESS); >>> t.body.length := 1 + Cstring.strlen (s); >>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>> END StoT; >>> >>> I'm not entirely sure why the old code works---why isn't the >>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>> In fact the pickler doesn't seem to know anything about TEXTs >>> at all. >>> >>> I see several possible ways of solving the problem. One is to >>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>> interface, there's no "legal" reason not to do that) and make sure >>> Params.Get (and everything else that could remotely be called >>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>> prominent warning signs, both in M3toC and Text8CString that "here >>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>> the C strings. I never liked the CM3 TEXTs, and I like them even >>> less now; I disliked them from the start because they broke pickle >>> compatibility with SRC M3, and now I find that they aren't even >>> compatible with themselves. >>> >>> Modula-3's strengths have always been its utter simplicity >>> and bullet-proof reliability. This stuff, where some objects are >>> more "serializable" than others, reminds me of Java! >>> >>> Does anyone have an opinion as to how this problem ought to be >>> solved? >>> >>> Mika >>> >>> Mika Nystrom writes: >>>> Hello everyone, >>>> >>>> Here's a random question that hopefully someone can answer... >>>> >>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>> >>>> Unless there's some magic I don't understand going on, I am >>>> thinking >>>> that would be the implication of: >>>> >>>> UNSAFE INTERFACE Text8CString; >>>> ... >>>> TYPE >>>> T <: Public; >>>> Public = TEXT OBJECT >>>> str: Ctypes.char_star; >>>> END; >>>> (* The array contains the characters of the text followed by a >>>> '\000'. *) >>>> ... >>>> >>>> I hope someone can set me straight and tell me that no, the >>>> situation >>>> isn't as dire as that---some clever thing somewhere makes it >>>> possible >>>> to Pickle all objects of type TEXT... >>>> >>>> Mika From mika at async.caltech.edu Fri Jul 27 17:04:14 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 27 Jul 2007 08:04:14 -0700 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: Your message of "Thu, 26 Jul 2007 12:02:19 EDT." Message-ID: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> Hi Tony, Sorry it took me a day to check up on this. I lost access to my 10.4 system and got my 10.3 back from Apple. You are right, your fix solved the pickle problem. Thank you very much, as always! Yes I realized it was doing something very tricky when I looked at the code... I also tested all my various software, and some of the CM3 programs, on 10.3. I can report the following: 1. The crash in Juno's virtual machine is gone 2. The threads taking 100% no longer do (I think this was the same bug that caused.. deadlock was it?.. on 10.4) 3. And of course the pickling is working great. But... 4. Bresenham still locks up for me. It does this, more often than not, on both 10.3 and 10.4. I'm really surprised it never does it for you! (Although it is true it sometimes work.) 5. I am still using @M3noincremental to run ktok, but it's the *only* program that seems to require it. Almost everything looks really good! Mika Tony Hosking writes: >I'm about to check in the fix. I have tested this with your example >program and things work fine. > >On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: > >> On closer inspection, it is even messier than that. In the old PM3 >> the text that is constructed is allocated in UNTRACED storage >> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >> GC'd, and looks (to the GC) like an (old-style) text literal >> allocated outside the heap. It is harder for us to fake up a text >> literal like this with the new TEXT setup since we'd need to >> allocate, copy, and loophole something that looks like a text >> literal (an object) in the untraced heap. The best alternative is >> to fix the pickler with a special that handles Text8Cstrings. I >> think this is the cleanest approach. Mika, please try the >> following program, which adds a special for Text8CString. I will >> put this code into the builtin specials for pickles. >> >> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >> >>> Looks like we need to fix M3toC.StoT so that it works the same as >>> old PM3. The old code works because it constructs a text *in* the >>> heap as an ARRAY OF CHAR, that just happens to have its payload >>> (the array contents) outside the heap. (Arrays in M3 contain a >>> reference to their data). We can play the same trick for >>> Text8CString and get things to work properly for you. I will make >>> this fix and check it in. >>> >>> >>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>> >>>> Ok, I am about to answer my own email. Here's a little program I >>>> wrote: >>>> >>>> MODULE Main; >>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>> >>>> VAR wr := NEW(TextWr.T).init(); >>>> toPickle := "pickle this"; >>>> BEGIN >>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>> >>>> Pickle.Write(wr,toPickle); >>>> >>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>> IO.Put("read back \""& >>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>> &"\"\n"); >>>> END Main. >>>> >>>> === On FreeBSD4 with my ancient, creaky PM3: >>>> >>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>> pickled "pickle that" >>>> read back "pickle that" >>>> >>>> === On PPC_DARWIN with the latest CM3: >>>> >>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>> pickled "pickle that" >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** >>>> >>>> Abort >>>> >>>> === On FreeBSD4 with the latest CM3: >>>> >>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>> pickled "pickle this" >>>> read back "pickle this" >>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>> pickled "pickle that" >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Segmentation violation - possible attempt to dereference NIL >>>> *** >>>> >>>> Abort >>>> >>>> ============ >>>> >>>> Diagnosis: >>>> >>>> The code I mentioned in a previous email declares a Text8CString.T >>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>> in the system, Ctypes.char_star is specifically declared to be an >>>> "UNTRACED REF Ctypes.char". According to the specification of >>>> Pickle, an UNTRACED REF is pickled as NIL. >>>> >>>> Generally speaking, you don't see many Text8CString.Ts in the >>>> system. >>>> This one comes in via Params.Get, which in turn calls RTArgs.GetArg, >>>> which in turn calls M3toC.StoT. >>>> >>>> StoT is generally not something you want to call, but it's supposed >>>> to be OK here because you're just passing around argv, which won't >>>> change. Generally speaking, it ought to be OK to use to convert >>>> C strings whose addresses aren't going to change during the lifetime >>>> of the program. >>>> >>>> I think it is *totally unacceptable* that Params.Get returns a >>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>> interfaces >>>> that warns of this fact, and it is surprising to say the least. >>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>> ever be required! Finally, there's no way of checking whether a >>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>>> >>>> What does baffle me a bit is that the code works on the old PM3. >>>> It uses the old TextF, which declares >>>> >>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>> >>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>> >>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>> VAR t := NEW (M3TextWithHeader); >>>> BEGIN >>>> t.header.typecode := RT0.TextTypecode; >>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>> t.body.length := 1 + Cstring.strlen (s); >>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>> END StoT; >>>> >>>> I'm not entirely sure why the old code works---why isn't the >>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>> In fact the pickler doesn't seem to know anything about TEXTs >>>> at all. >>>> >>>> I see several possible ways of solving the problem. One is to >>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>> interface, there's no "legal" reason not to do that) and make sure >>>> Params.Get (and everything else that could remotely be called >>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>> prominent warning signs, both in M3toC and Text8CString that "here >>>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>> less now; I disliked them from the start because they broke pickle >>>> compatibility with SRC M3, and now I find that they aren't even >>>> compatible with themselves. >>>> >>>> Modula-3's strengths have always been its utter simplicity >>>> and bullet-proof reliability. This stuff, where some objects are >>>> more "serializable" than others, reminds me of Java! >>>> >>>> Does anyone have an opinion as to how this problem ought to be >>>> solved? >>>> >>>> Mika >>>> >>>> Mika Nystrom writes: >>>>> Hello everyone, >>>>> >>>>> Here's a random question that hopefully someone can answer... >>>>> >>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>> >>>>> Unless there's some magic I don't understand going on, I am >>>>> thinking >>>>> that would be the implication of: >>>>> >>>>> UNSAFE INTERFACE Text8CString; >>>>> ... >>>>> TYPE >>>>> T <: Public; >>>>> Public = TEXT OBJECT >>>>> str: Ctypes.char_star; >>>>> END; >>>>> (* The array contains the characters of the text followed by a >>>>> '\000'. *) >>>>> ... >>>>> >>>>> I hope someone can set me straight and tell me that no, the >>>>> situation >>>>> isn't as dire as that---some clever thing somewhere makes it >>>>> possible >>>>> to Pickle all objects of type TEXT... >>>>> >>>>> Mika From hosking at cs.purdue.edu Fri Jul 27 18:40:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Jul 2007 12:40:44 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> References: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> Message-ID: <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> On Jul 27, 2007, at 11:04 AM, Mika Nystrom wrote: > Hi Tony, > > Sorry it took me a day to check up on this. I lost access to my > 10.4 system and got my 10.3 back from Apple. > > You are right, your fix solved the pickle problem. Thank you very > much, > as always! Yes I realized it was doing something very tricky when I > looked at the code... > > I also tested all my various software, and some of the CM3 > programs, on > 10.3. I can report the following: > > 1. The crash in Juno's virtual machine is gone > 2. The threads taking 100% no longer do (I think this was the same > bug that > caused.. deadlock was it?.. on 10.4) > 3. And of course the pickling is working great. Great! > But... > > 4. Bresenham still locks up for me. It does this, more often than > not, > on both 10.3 and 10.4. I'm really surprised it never does it for you! > (Although it is true it sometimes work.) Yes, this problem seems to manifest only on Darwin, and I am seeing the issue with Bresenham as you do. I think it is a VBT issue that I have isolated to the following small program, which works fine for me on Linux, but which has always caused problems on Darwin locking up and not responding (I strongly suspect the Darwin X implementation rather than the threads system, but need still to diagnose the issue): MODULE Main; IMPORT ButtonVBT, HighlightVBT, VBT, TextVBT, Filter, Text, Trestle, BorderedVBT, Compiler, RTIO; PROCEDURE Flip(b: ButtonVBT.T; <*UNUSED*> READONLY cd: VBT.MouseRec) RAISES {}= BEGIN WITH ch = Filter.Child(b), txt = TextVBT.Get(ch) DO IF Text.Equal(txt, "Alpha") THEN TextVBT.Put(ch, "Beta") ELSE TextVBT.Put(ch, "Alpha") END END END Flip; VAR button := ButtonVBT.New(TextVBT.New("Alpha"), Flip); root := BorderedVBT.New(button); BEGIN RTIO.PutText(Compiler.ThisFile()); RTIO.PutChar('\n'); RTIO.PutText(Compiler.ThisPath()); RTIO.PutChar('\n'); RTIO.PutInt(Compiler.ThisLine()); RTIO.PutChar('\n'); RTIO.Flush(); Trestle.Install(root); Trestle.AwaitDelete(root); END Main. > 5. I am still using @M3noincremental to run ktok, but it's the *only* > program that seems to require it. I would like to figure this one out soon, as it really is a worry to me -- I am concerned that the new incremental GC support be as robust as possible and this is the only outstanding issue with it of which I am aware. > > Almost everything looks really good! > > Mika > > Tony Hosking writes: >> I'm about to check in the fix. I have tested this with your example >> program and things work fine. >> >> On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: >> >>> On closer inspection, it is even messier than that. In the old PM3 >>> the text that is constructed is allocated in UNTRACED storage >>> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >>> GC'd, and looks (to the GC) like an (old-style) text literal >>> allocated outside the heap. It is harder for us to fake up a text >>> literal like this with the new TEXT setup since we'd need to >>> allocate, copy, and loophole something that looks like a text >>> literal (an object) in the untraced heap. The best alternative is >>> to fix the pickler with a special that handles Text8Cstrings. I >>> think this is the cleanest approach. Mika, please try the >>> following program, which adds a special for Text8CString. I will >>> put this code into the builtin specials for pickles. >>> >>> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >>> >>>> Looks like we need to fix M3toC.StoT so that it works the same as >>>> old PM3. The old code works because it constructs a text *in* the >>>> heap as an ARRAY OF CHAR, that just happens to have its payload >>>> (the array contents) outside the heap. (Arrays in M3 contain a >>>> reference to their data). We can play the same trick for >>>> Text8CString and get things to work properly for you. I will make >>>> this fix and check it in. >>>> >>>> >>>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>>> >>>>> Ok, I am about to answer my own email. Here's a little program I >>>>> wrote: >>>>> >>>>> MODULE Main; >>>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>>> >>>>> VAR wr := NEW(TextWr.T).init(); >>>>> toPickle := "pickle this"; >>>>> BEGIN >>>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>>> >>>>> Pickle.Write(wr,toPickle); >>>>> >>>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>>> IO.Put("read back \""& >>>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>>> &"\"\n"); >>>>> END Main. >>>>> >>>>> === On FreeBSD4 with my ancient, creaky PM3: >>>>> >>>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> read back "pickle that" >>>>> >>>>> === On PPC_DARWIN with the latest CM3: >>>>> >>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference >>>>> NIL >>>>> *** >>>>> >>>>> Abort >>>>> >>>>> === On FreeBSD4 with the latest CM3: >>>>> >>>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>>> pickled "pickle this" >>>>> read back "pickle this" >>>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>> pickled "pickle that" >>>>> >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** Segmentation violation - possible attempt to dereference >>>>> NIL >>>>> *** >>>>> >>>>> Abort >>>>> >>>>> ============ >>>>> >>>>> Diagnosis: >>>>> >>>>> The code I mentioned in a previous email declares a Text8CString.T >>>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>>> in the system, Ctypes.char_star is specifically declared to be an >>>>> "UNTRACED REF Ctypes.char". According to the specification of >>>>> Pickle, an UNTRACED REF is pickled as NIL. >>>>> >>>>> Generally speaking, you don't see many Text8CString.Ts in the >>>>> system. >>>>> This one comes in via Params.Get, which in turn calls >>>>> RTArgs.GetArg, >>>>> which in turn calls M3toC.StoT. >>>>> >>>>> StoT is generally not something you want to call, but it's >>>>> supposed >>>>> to be OK here because you're just passing around argv, which won't >>>>> change. Generally speaking, it ought to be OK to use to convert >>>>> C strings whose addresses aren't going to change during the >>>>> lifetime >>>>> of the program. >>>>> >>>>> I think it is *totally unacceptable* that Params.Get returns a >>>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>>> interfaces >>>>> that warns of this fact, and it is surprising to say the least. >>>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>>> ever be required! Finally, there's no way of checking whether a >>>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>>> an UNSAFE INTERFACE, which of course is illegal in a safe MODULE!! >>>>> >>>>> What does baffle me a bit is that the code works on the old PM3. >>>>> It uses the old TextF, which declares >>>>> >>>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>>> >>>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>>> >>>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>>> VAR t := NEW (M3TextWithHeader); >>>>> BEGIN >>>>> t.header.typecode := RT0.TextTypecode; >>>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>>> t.body.length := 1 + Cstring.strlen (s); >>>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>>> END StoT; >>>>> >>>>> I'm not entirely sure why the old code works---why isn't the >>>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>>> In fact the pickler doesn't seem to know anything about TEXTs >>>>> at all. >>>>> >>>>> I see several possible ways of solving the problem. One is to >>>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>>> interface, there's no "legal" reason not to do that) and make sure >>>>> Params.Get (and everything else that could remotely be called >>>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>>> prominent warning signs, both in M3toC and Text8CString that "here >>>>> be demons". Another is to revert to the SRC method of LOOPHOLEing >>>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>>> less now; I disliked them from the start because they broke pickle >>>>> compatibility with SRC M3, and now I find that they aren't even >>>>> compatible with themselves. >>>>> >>>>> Modula-3's strengths have always been its utter simplicity >>>>> and bullet-proof reliability. This stuff, where some objects are >>>>> more "serializable" than others, reminds me of Java! >>>>> >>>>> Does anyone have an opinion as to how this problem ought to be >>>>> solved? >>>>> >>>>> Mika >>>>> >>>>> Mika Nystrom writes: >>>>>> Hello everyone, >>>>>> >>>>>> Here's a random question that hopefully someone can answer... >>>>>> >>>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>>> >>>>>> Unless there's some magic I don't understand going on, I am >>>>>> thinking >>>>>> that would be the implication of: >>>>>> >>>>>> UNSAFE INTERFACE Text8CString; >>>>>> ... >>>>>> TYPE >>>>>> T <: Public; >>>>>> Public = TEXT OBJECT >>>>>> str: Ctypes.char_star; >>>>>> END; >>>>>> (* The array contains the characters of the text followed by a >>>>>> '\000'. *) >>>>>> ... >>>>>> >>>>>> I hope someone can set me straight and tell me that no, the >>>>>> situation >>>>>> isn't as dire as that---some clever thing somewhere makes it >>>>>> possible >>>>>> to Pickle all objects of type TEXT... >>>>>> >>>>>> Mika From hosking at cs.purdue.edu Fri Jul 27 19:23:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Jul 2007 13:23:43 -0400 Subject: [M3devel] Question about TEXTs under CM3 In-Reply-To: <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> References: <200707271504.l6RF4E0x036464@camembert.async.caltech.edu> <26CFE9CA-1160-4DAF-85B1-1D3465CE31B5@cs.purdue.edu> Message-ID: <7120B06C-A59A-4509-A857-E5B9A72206E6@cs.purdue.edu> On Jul 27, 2007, at 12:40 PM, Tony Hosking wrote: > > On Jul 27, 2007, at 11:04 AM, Mika Nystrom wrote: > >> Hi Tony, >> >> Sorry it took me a day to check up on this. I lost access to my >> 10.4 system and got my 10.3 back from Apple. >> >> You are right, your fix solved the pickle problem. Thank you very >> much, >> as always! Yes I realized it was doing something very tricky when I >> looked at the code... >> >> I also tested all my various software, and some of the CM3 >> programs, on >> 10.3. I can report the following: >> >> 1. The crash in Juno's virtual machine is gone >> 2. The threads taking 100% no longer do (I think this was the same >> bug that >> caused.. deadlock was it?.. on 10.4) >> 3. And of course the pickling is working great. > > Great! > >> But... >> >> 4. Bresenham still locks up for me. It does this, more often than >> not, >> on both 10.3 and 10.4. I'm really surprised it never does it for >> you! >> (Although it is true it sometimes work.) > > Yes, this problem seems to manifest only on Darwin, and I am seeing > the issue with Bresenham as you do. I think it is a VBT issue that > I have isolated to the following small program, which works fine > for me on Linux, but which has always caused problems on Darwin > locking up and not responding (I strongly suspect the Darwin X > implementation rather than the threads system, but need still to > diagnose the issue): > > MODULE Main; > > IMPORT ButtonVBT, HighlightVBT, VBT, TextVBT, Filter, Text, > Trestle, BorderedVBT, > Compiler, RTIO; > > PROCEDURE Flip(b: ButtonVBT.T; <*UNUSED*> READONLY cd: > VBT.MouseRec) RAISES {}= > BEGIN > WITH ch = Filter.Child(b), txt = TextVBT.Get(ch) DO > IF Text.Equal(txt, "Alpha") THEN > TextVBT.Put(ch, "Beta") > ELSE > TextVBT.Put(ch, "Alpha") > END > END > END Flip; > > VAR > button := ButtonVBT.New(TextVBT.New("Alpha"), Flip); > root := BorderedVBT.New(button); > > BEGIN > RTIO.PutText(Compiler.ThisFile()); RTIO.PutChar('\n'); > RTIO.PutText(Compiler.ThisPath()); RTIO.PutChar('\n'); > RTIO.PutInt(Compiler.ThisLine()); RTIO.PutChar('\n'); > RTIO.Flush(); > Trestle.Install(root); > Trestle.AwaitDelete(root); > END Main. The fix for this program is to set Xquartz defaults as follows (see the manual to see how to do this): defaults write com.apple.x11 wm_click_through -bool true I have still not diagnosed the issue with mentor running Bresenham. > > >> 5. I am still using @M3noincremental to run ktok, but it's the *only* >> program that seems to require it. > > I would like to figure this one out soon, as it really is a worry > to me -- I am concerned that the new incremental GC support be as > robust as possible and this is the only outstanding issue with it > of which I am aware. > >> >> Almost everything looks really good! >> >> Mika >> >> Tony Hosking writes: >>> I'm about to check in the fix. I have tested this with your example >>> program and things work fine. >>> >>> On Jul 26, 2007, at 11:26 AM, Tony Hosking wrote: >>> >>>> On closer inspection, it is even messier than that. In the old PM3 >>>> the text that is constructed is allocated in UNTRACED storage >>>> (M3TextWithHeader is an UNTRACED REF RECORD...) so it can't be >>>> GC'd, and looks (to the GC) like an (old-style) text literal >>>> allocated outside the heap. It is harder for us to fake up a text >>>> literal like this with the new TEXT setup since we'd need to >>>> allocate, copy, and loophole something that looks like a text >>>> literal (an object) in the untraced heap. The best alternative is >>>> to fix the pickler with a special that handles Text8Cstrings. I >>>> think this is the cleanest approach. Mika, please try the >>>> following program, which adds a special for Text8CString. I will >>>> put this code into the builtin specials for pickles. >>>> >>>> On Jul 26, 2007, at 9:47 AM, Tony Hosking wrote: >>>> >>>>> Looks like we need to fix M3toC.StoT so that it works the same as >>>>> old PM3. The old code works because it constructs a text *in* the >>>>> heap as an ARRAY OF CHAR, that just happens to have its payload >>>>> (the array contents) outside the heap. (Arrays in M3 contain a >>>>> reference to their data). We can play the same trick for >>>>> Text8CString and get things to work properly for you. I will make >>>>> this fix and check it in. >>>>> >>>>> >>>>> On Jul 26, 2007, at 8:40 AM, Mika Nystrom wrote: >>>>> >>>>>> Ok, I am about to answer my own email. Here's a little program I >>>>>> wrote: >>>>>> >>>>>> MODULE Main; >>>>>> IMPORT Pickle, IO, Params, TextWr, TextRd; >>>>>> >>>>>> VAR wr := NEW(TextWr.T).init(); >>>>>> toPickle := "pickle this"; >>>>>> BEGIN >>>>>> IF Params.Count > 1 THEN toPickle := Params.Get(1) END; >>>>>> >>>>>> Pickle.Write(wr,toPickle); >>>>>> >>>>>> IO.Put("pickled \""&toPickle&"\"\n"); >>>>>> IO.Put("read back \""& >>>>>> Pickle.Read(NEW(TextRd.T).init(TextWr.ToText(wr))) >>>>>> &"\"\n"); >>>>>> END Main. >>>>>> >>>>>> === On FreeBSD4 with my ancient, creaky PM3: >>>>>> >>>>>> (64)trs80:~/ptest/src>../FreeBSD4/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> (65)trs80:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> read back "pickle that" >>>>>> >>>>>> === On PPC_DARWIN with the latest CM3: >>>>>> >>>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> [QT:~/ptest/src] mika% ../PPC_DARWIN/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to >>>>>> dereference NIL >>>>>> *** >>>>>> >>>>>> Abort >>>>>> >>>>>> === On FreeBSD4 with the latest CM3: >>>>>> >>>>>> (73)rover:~/ptest/src>../FreeBSD4/pickleit >>>>>> pickled "pickle this" >>>>>> read back "pickle this" >>>>>> (74)rover:~/ptest/src>../FreeBSD4/pickleit pickle\ that >>>>>> pickled "pickle that" >>>>>> >>>>>> >>>>>> *** >>>>>> *** runtime error: >>>>>> *** Segmentation violation - possible attempt to >>>>>> dereference NIL >>>>>> *** >>>>>> >>>>>> Abort >>>>>> >>>>>> ============ >>>>>> >>>>>> Diagnosis: >>>>>> >>>>>> The code I mentioned in a previous email declares a >>>>>> Text8CString.T >>>>>> to be of type TEXT OBJECT str: Ctypes.char_star; END . Elsewhere >>>>>> in the system, Ctypes.char_star is specifically declared to be an >>>>>> "UNTRACED REF Ctypes.char". According to the specification of >>>>>> Pickle, an UNTRACED REF is pickled as NIL. >>>>>> >>>>>> Generally speaking, you don't see many Text8CString.Ts in the >>>>>> system. >>>>>> This one comes in via Params.Get, which in turn calls >>>>>> RTArgs.GetArg, >>>>>> which in turn calls M3toC.StoT. >>>>>> >>>>>> StoT is generally not something you want to call, but it's >>>>>> supposed >>>>>> to be OK here because you're just passing around argv, which >>>>>> won't >>>>>> change. Generally speaking, it ought to be OK to use to convert >>>>>> C strings whose addresses aren't going to change during the >>>>>> lifetime >>>>>> of the program. >>>>>> >>>>>> I think it is *totally unacceptable* that Params.Get returns a >>>>>> "poisoned" TEXT. There is absolutely nothing in any of the >>>>>> interfaces >>>>>> that warns of this fact, and it is surprising to say the least. >>>>>> There is also no simple way of "copying" TEXTs, as it shouldn't >>>>>> ever be required! Finally, there's no way of checking whether a >>>>>> TEXT is a Text8CString.T without importing Text8CString, which is >>>>>> an UNSAFE INTERFACE, which of course is illegal in a safe >>>>>> MODULE!! >>>>>> >>>>>> What does baffle me a bit is that the code works on the old PM3. >>>>>> It uses the old TextF, which declares >>>>>> >>>>>> TEXT = BRANDED Text.Brand REF ARRAY OF CHAR; >>>>>> >>>>>> The old (from PM3, I think it's 1.1.15) M3toC has: >>>>>> >>>>>> PROCEDURE StoT (s: Ctypes.char_star): TEXT = >>>>>> VAR t := NEW (M3TextWithHeader); >>>>>> BEGIN >>>>>> t.header.typecode := RT0.TextTypecode; >>>>>> t.body.chars := LOOPHOLE (s, ADDRESS); >>>>>> t.body.length := 1 + Cstring.strlen (s); >>>>>> RETURN LOOPHOLE (ADR (t.body), TEXT); >>>>>> END StoT; >>>>>> >>>>>> I'm not entirely sure why the old code works---why isn't the >>>>>> M3TextWithHeader garbage-collected? The pickler doesn't seem to >>>>>> know that the result of LOOPHOLE (ADR (t.body), TEXT) is special. >>>>>> In fact the pickler doesn't seem to know anything about TEXTs >>>>>> at all. >>>>>> >>>>>> I see several possible ways of solving the problem. One is to >>>>>> permit M3toC.StoT to remain broken (since M3toC is an UNSAFE >>>>>> interface, there's no "legal" reason not to do that) and make >>>>>> sure >>>>>> Params.Get (and everything else that could remotely be called >>>>>> "standard") doesn't use M3toC.StoT---oh and to leave some very >>>>>> prominent warning signs, both in M3toC and Text8CString that >>>>>> "here >>>>>> be demons". Another is to revert to the SRC method of >>>>>> LOOPHOLEing >>>>>> the C strings. I never liked the CM3 TEXTs, and I like them even >>>>>> less now; I disliked them from the start because they broke >>>>>> pickle >>>>>> compatibility with SRC M3, and now I find that they aren't even >>>>>> compatible with themselves. >>>>>> >>>>>> Modula-3's strengths have always been its utter simplicity >>>>>> and bullet-proof reliability. This stuff, where some objects are >>>>>> more "serializable" than others, reminds me of Java! >>>>>> >>>>>> Does anyone have an opinion as to how this problem ought to be >>>>>> solved? >>>>>> >>>>>> Mika >>>>>> >>>>>> Mika Nystrom writes: >>>>>>> Hello everyone, >>>>>>> >>>>>>> Here's a random question that hopefully someone can answer... >>>>>>> >>>>>>> Is it true that certain TEXTs can't be Pickled under CM3? >>>>>>> >>>>>>> Unless there's some magic I don't understand going on, I am >>>>>>> thinking >>>>>>> that would be the implication of: >>>>>>> >>>>>>> UNSAFE INTERFACE Text8CString; >>>>>>> ... >>>>>>> TYPE >>>>>>> T <: Public; >>>>>>> Public = TEXT OBJECT >>>>>>> str: Ctypes.char_star; >>>>>>> END; >>>>>>> (* The array contains the characters of the text followed by a >>>>>>> '\000'. *) >>>>>>> ... >>>>>>> >>>>>>> I hope someone can set me straight and tell me that no, the >>>>>>> situation >>>>>>> isn't as dire as that---some clever thing somewhere makes it >>>>>>> possible >>>>>>> to Pickle all objects of type TEXT... >>>>>>> >>>>>>> Mika From elmstb at aon.at Wed Jul 4 20:33:14 2007 From: elmstb at aon.at (Elmar Stellnberger) Date: Wed, 04 Jul 2007 18:33:14 -0000 Subject: [M3devel] User-level threading In-Reply-To: <468BE2F4.7010805@aon.at> References: <9E8A216A-0F81-4550-80A0-20BAA0D2CC7D@cs.purdue.edu> <468BE2F4.7010805@aon.at> Message-ID: <468BE796.8020802@aon.at> It seems to be the same message, which I have sent to you. Has there been anything new you wanted to tell me? Is the setjmp/longjmp replacement of interest? Elmar Stellnberger wrote: > Not long ago I have fixed this problem by replacing setjmp/longjmp with > my own i386 - implementations of these functions for SRC-M3. The result > seems to be stable and correct. > However this may be less favourable than using makecontext since the > assembler routines will only work on i386 hardware. > Moreover setjmp/longjmp are said that they may cause the loss of > assignents, because they do not save certain registers(cx,dx) -> see > "Exception semantics" at > http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/restrictions.html. > Nevertheless possible future changes on make/get/setcontext will not be > able to affect Modula-3 when extracting the SP from the context record > any more if it does not rely on glibc functions. > Another solution is to link against the old glibc files (unpacked into > /lib/anc): > > >> ldd $(which m3build) >> > linux-gate.so.1 => (0xffffe000) > libm3front.so.1 => > /usr/local/m3/lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) > libm.so.6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) > libc.so.6 => /lib/anc/9.3/libc.so.6 (0xb7c95000) > /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000) > > Please tell me if you are intereseted in any of both solutions. > I would suppose a solution for CM3 not to differ that much. > > Yours, > Elmar Stellnberger > > > > Tony Hosking wrote: > >> I have a question that may influence the direction we take with >> user-level threading support. Currently, user-level threading is >> broken on platforms that implement secure setjmp/longjmp via >> encryption since hacking the jump buffers the way we currently do for >> user-level threading triggers longjmp errors. A better alternative is >> to use makecontext/getcontext/setcontext on platforms that support it. >> For example, I know of the following situation for the targets I track: >> >> Target System (pthreads) threads User (setjmp/longjmp) threads User >> (getcontext/setcontext) threads >> >> LINUXLIBC6 YES NO unimplemented >> SOLgnu YES unimplemented YES (but not using makecontext) >> PPC_DARWIN YES NO no getcontext/setcontext >> I386_DARWIN YES NO no getcontext/setcontext >> FreeBSD NO YES unimplemented >> >> Ideally, we would implement all user-level threading using makecontext >> and friends, but my question is how many of our user-level threading >> targets actually support that API? One strategy would be to >> re-implement user-level threading using makecontext, etc., but fake up >> makecontext support, etc., on those targets that don't have it. >> >> I would hate to lose the user-level thread support just because it >> makes sense in some situations (e.g., embedded, uni-processor). >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Fri Jul 13 18:17:34 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 13 Jul 2007 16:17:34 -0000 Subject: [M3devel] CVS deprecated info strings? In-Reply-To: <46979D85.3060001@wichita.edu> References: <46979D85.3060001@wichita.edu> Message-ID: <20070713161515.GC98227@ted.stsp.lan> On Fri, Jul 13, 2007 at 10:43:01AM -0500, Rodney M. Bates wrote: > I just got this message from CVS: > > cvs commit: Using deprecated info format strings. Convert your scripts to > use > the new argument format and remove '1's from your info file format strings. > > I am guessing this refers to stylized comments in the file(s) I committed. No. It's a known issue. > Any pointers to documentation on what CVS really wants here? http://ximbiot.com/cvs/manual/cvs-1.12.6/cvs_18.html#SEC168 -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rcoleburn at scires.com Thu Jul 19 20:56:22 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 19 Jul 2007 18:56:22 -0000 Subject: [M3devel] LONGINT In-Reply-To: References: Message-ID: <469F7BAD.1E75.00D7.1@scires.com> Tony: I'd like to better understand the implications of your change as I do use LONGINT as an index in some applications. 1. On a computer with a 32-bit word size, will LONGINT be 32 bits or 64 bits? 2. I assume on a computer with a 64-bit word size, LONGINT will be 64 bits. Is there an option to get a 32-bit integer on these machines? 3. Would it make sense to keep LONGINT at 32-bits and make a new type, say LONGINT64, at 64-bits? Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> Tony Hosking 7/18/2007 11:53 PM >>> I've successfully bootstrapped a CM3 compiler that supports LONGINT as a 64-bit integer type (equivalent to "long long" in C) in addition to INTEGER (same as "long" in C). This will be useful for simplifying interfaces to C library routines that expect to be able to treat 64-bit integers such as "off_t" for lseek, etc. Currently, the compiler does not treat LONGINT as an ordinal type (I'm not sure this would ever be a good idea) so it cannot be used to index arrays, define enumerations etc., though the simple operations ABS, MAX, MIN, addition, comparisons, MOD, multiplication, subtraction, assignment, are all supported. This includes changes to m3core (with support for Long.T similar to Word.T, plus RTTipe and RTTypeMap, etc.) and libm3 for Pickle2, as well as to m3middle, m3front, and the gcc-based compiler backend. There is still work that needs to be done to support and test all the other M3 tools such as network objects, etc., with support and testing needed in m3tk for the new type, as well as in other tools like m3browser. How best should I proceed to get this out to the community. I am tempted to push it into the CVS head just so that it gets some testing, but perhaps that is premature. I can confirm a complete bootstrap via "do-cm3-std.sh" that appears to produce perfectly functional executables, including mentor, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jul 20 22:48:34 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 20 Jul 2007 20:48:34 -0000 Subject: [M3devel] [Fwd: Re: A nonnative 64-bit language proposal] In-Reply-To: <469FDFDE.9020201@wichita.edu> References: <200610260605.k9Q65Uss072339@camembert.async.caltech.edu> <469FA095.2000404@wichita.edu> <2B3525DB-172B-4C3A-BB0F-7EB34D1E4431@darko.org> <8DF7F5AF-058F-4B39-99DD-19DB3BC148C5@cs.purdue.edu> <8DFDDD51-DDB6-4B89-85B3-791E7073C6B5@darko.org> <469FDFDE.9020201@wichita.edu> Message-ID: <05CD4EBC-E1C6-4BB7-919C-8032B5265609@cs.purdue.edu> I think I am coming around to Rodney's position. We should consider INTEGER and LONGINT assignable under the current rules for subranges. Thus, INTEGER := LONGINT will cause a range check (and underlying conversion of the integer value from BITSIZE(LONGINT) to BITSIZE(INTEGER)), whereas LONGINT := INTEGER will need not check (though the conversion will be necessary to extend sign as expected). I believe this functionality can easily be implemented in the current compiler. Also, I am willing to allow indexing of arrays using LONGINT-based ordinals for the index type. The usual restrictions on array size will obtain, and zero-based array indexes will be computed into integer offsets. Thus, for an array indexed [minL..maxL] where minL and maxL have base type LONGINT, the offset will be computed as: index - minL and converted to an INTEGER value to index the array. Because of the sizing restriction, index - minL must be expressible as an INTEGER. Here are my revised notes: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: longint.txt URL: -------------- next part -------------- On Jul 19, 2007, at 6:04 PM, Rodney M. Bates wrote: > > > Tony Hosking wrote: >> On Jul 19, 2007, at 4:33 PM, Darko wrote: >>> I actually favour a implicit conversion, which for this >>> particular case I think would be consistent with existing M3 >>> behaviour. >> There is no implicit conversion for floats. The danger with >> implicit conversion for integers is that it would not be >> portable: you would get different behavior on different machines >> for the same code. Better to make the conversion explicit so >> that programmers are prepared for the range check to fail. > > But is this argument any stronger for requiring explicit conversions > for INTEGER/LONGINT assignments than for assigning to subranges? > Many assignments in the language now, without any type conversion, > admit the possibility of RT range errors. And these can be dependent > on the size of INTEGER too. Consider: > > VAR V : [ 0 .. 65535 ] ; > VAR I : CARDINAL ; > ... > V := I DIV 2 ; > > I think for portability, the principle that the static semantics > should be > the same for all sizes of INTEGER (and LONGINT too) is as much as > we can > hope for. Certainly, there are already countless ways the integer > size can > change the dynamic semantics of a program. > > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu