<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>I upgrade across incompatibilities frequently & Hudson does now too. The existing scripts work very well and you would be foolish to not use them. Just use upgrade.py. It is very easy. Or upgrade.py nocleangcc. And then do-cm3-all.py skipgcc realclean && do-cm3-all.py buildship.py.<br><br> - Jay/phone<br><br>> To: jay.krell@cornell.edu<br>> Date: Sat, 8 Jan 2011 04:14:41 -0800<br>> From: mika@async.caltech.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] another Snow Leopard compiler crash<br>> <br>> Jay K writes:<br>> ><br>> >Please try this Mika. It fixes the problem for me.<br>> <br>> Hi Jay,<br>> <br>> So I upgraded to the CVS head and now I get a segfaulting compiler:<br>> <br>> [hal:cm3/m3-libs/m3core] mika% gdb $CM3<br>> GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010)<br>> Copyright 2004 Free Software Foundation, Inc.<br>> GDB is free software, covered by the GNU General Public License, and you are<br>> welcome to change it and/or distribute copies of it under certain conditions.<br>> Type "show copying" to see the conditions.<br>> There is absolutely no warranty for GDB.  Type "show warranty" for details.<br>> This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...... done<br>> <br>> (gdb) run<br>> Starting program: /usr/local/cm3/pkg/cm3/I386_DARWIN/cm3 <br>> Reading symbols for shared libraries .+++++.......... done<br>> <br>> Program received signal EXC_BAD_ACCESS, Could not access memory.<br>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000038b<br>> 0x9713354b in _longjmp ()<br>> (gdb) where<br>> #0  0x9713354b in _longjmp ()<br>> #1  0x00285d2b in RTExFrame__InvokeHandler (f=0xbffff34c, a=0xbffff23c) at ../src/runtime/ex_frame/RTExFrame.m3:175<br>> #2  0x00285be4 in RTException__ResumeRaise (a=0xbffff23c) at ../src/runtime/ex_frame/RTExFrame.m3:145<br>> #3  0x00285a1b in RTException__Raise (act=0xbffff23c) at ../src/runtime/ex_frame/RTExFrame.m3:91<br>> #4  0x00269d44 in RTHooks__Raise (ex=0x35a720, arg=0x181cddc, module=0x398080, line=50) at ../src/runtime/common/RTHooks.m3:79<br>> #5  0x0023adbc in OSErrorPosix__Raise0 (errno=2) at ../src/os/POSIX/OSErrorPosix.m3:50<br>> #6  0x0023cffc in FSPosix__Fail (p=0x181cdc0, f=0xf049f0) at ../src/os/POSIX/FSPosix.m3:359<br>> #7  0x0023cdd4 in FS__Status (pn=0x181cdc0, _result=0xbffff3c8) at ../src/os/POSIX/FSPosix.m3:328<br>> #8  0x00217d24 in M3File__IsReadable (path=0x181cdc0) at ../src/M3File.m3:123<br>> #9  0x000a057f in MxConfig__TryConfig (a=0x3255e0, b=0x3255f0, c=0x0) at ../src/MxConfig.m3:122<br>> #10 0x0009ff67 in MxConfig__FindConfig () at ../src/MxConfig.m3:51<br>> #11 0x0009fcd8 in MxConfig__FindFile () at ../src/MxConfig.m3:19<br>> #12 0x0002c446 in Main__DoIt () at ../src/Main.m3:32<br>> #13 0x0002d1e9 in Main_M3 (mode=1) at ../src/Main.m3:214<br>> #14 0x0027a781 in RTLinker__RunMainBody (m=0x3705a0) at ../src/runtime/common/RTLinker.m3:406<br>> #15 0x00279bb6 in RTLinker__AddUnitI (m=0x3705a0) at ../src/runtime/common/RTLinker.m3:113<br>> #16 0x00279c3a in RTLinker__AddUnit (b=0x2d1d0) at ../src/runtime/common/RTLinker.m3:122<br>> #17 0x00002cfc in main (argc=1, argv=0xbffff674, envp=0xbffff67c) at _m3main.c:16<br>> (gdb) <br>> <br>> I followed upgrade instructions from Tony (including upgrading the<br>> back-end)---I have edited the instructions a bit to track changes in <br>> CM3.  I'm starting from head three weeks old..<br>> <br>>       Mika<br>> <br>> <br>> Return-Path: hosking@cs.purdue.edu<br>> Delivery-Date: Sun Jun 24 07:38:38 2007<br>> In-Reply-To: <200706231838.l5NIcRef079333@camembert.async.caltech.edu><br>> References: <200706231838.l5NIcRef079333@camembert.async.caltech.edu><br>> <br>> Sounds like we really need some work done in this area.  I very  <br>> rarely use the build scripts, since I bootstrap manually from old  <br>> compilers to new compilers rather than use the scripts.  I suggest  <br>> the following approach, which I hope you will try, and then report  <br>> back on.<br>> <br>> Install the bootstrap compiler as you did originally:<br>> <br>> > rm -rf /usr/local/cm3/*<br>> ><br>> > cd ~/cm3-cvs<br>> > mkdir boot<br>> > cd boot<br>> > tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz<br>> > ./cminstall<br>> <br>> <br>> Now you will have some kind of cm3 installed, presumably in /usr/ <br>> local/cm3/bin/cm3.<br>> <br>> Make sure you have a fresh CVS checkout in directory cm3 (let's  <br>> assume this is in your home directory ~/cm3).  Also, make sure you  <br>> have an up-to-date version of the CM3 backend compiler cm3cg  <br>> installed by executing the following:<br>> <br>> STEP 0:<br>> <br>> export CM3=/usr/local/cm3/bin/cm3<br>> cd ~/cm3/m3-sys/m3cc<br>> $CM3<br>> $CM3 -ship<br>> <br>> You can skip this last step if you know your backend compiler is up  <br>> to date.<br>> <br>> Now, let's build the new compiler from scratch (this is the sequence  <br>> I use regularly to test changes to the run-time system whenever I  <br>> make them):<br>> <br>> can replace compilation step with<br>> <br>> rm -rf <der. dir> && $CM3 && $CM3 -ship <br>> <br>> <br>> STEP 1:<br>> <br>> (do these LATER if bootstrapping from old compiler!)<br>> cd ~/cm3/m3-libs/m3core<br>> $CM3<br>> $CM3 -ship<br>> cd ~/cm3/m3-libs/libm3<br>> $CM3<br>> $CM3 -ship<br>> <br>> Now build the compiler:<br>> <br>> cd  ~/cm3/m3-libs/sysutils ; $CM3 etc.<br>> <br>> cd ~/cm3/m3-sys/m3middle; $CM3 etc.<br>> <br>> repeat for:<br>> <br>> m3-sys/m3objfile <br>> <br>> m3-sys/m3back <br>> <br>> m3-sys/m3linker<br>> <br>> m3-sys/m3front<br>> <br>> m3-sys/m3quake<br>> <br>> m3-sys/cm3<br>> <br>> [ here we may need -DROOT=<root dir, e.g., /home/mika/cm3> ]<br>> <br>> <br>> At this point you should have a bootstrapped version of cm3 installed  <br>> in the directory /usr/local/cm3/pkg/cm3/TARGET/cm3 (where TARGET is  <br>> the CM3 target platform you are building on -- e.g., LINUXLIBC6,  <br>> PPC_DARWIN, ...).  Note that this did not overwrite your original  <br>> installed compiler in /usr/local/cm3/bin/cm3.  We<br>> are now going to test the new compiler, which was built using the old  <br>> compiler, by bootstrapping it one more time.<br>> <br>> <br>> ******* THIS IS WHERE I HAVE A SEGFAULTING COMPILER *******<br>> <br>> (If m3core and libm3 were skipped earlier, do them now, and RE-DO all<br>> of the above packages before proceeding.)<br>> <br>> From here on out, please replace TARGET with your target platform as  <br>> appropriate.<br>> <br>> STEP 2:<br>> <br>> export CM3=/usr/local/cm3/pkg/cm3/TARGET/cm3<br>> cd ~/cm3/scripts<br>> <br>> ./do-cm3-std.sh realclean<br>> REPEAT STEP 1 to rebuild the libraries and the compiler using the  <br>> STEP 1 bootstrap compiler.<br>> <br>> Now you have a STEP 2 bootstrap compiler installed in /usr/local/cm3/ <br>> pkg/cm3/TARGET/cm3.  Let's assume the new compiler now works properly  <br>> since it successfully bootstrapped itself, but to be sure we can now  <br>> use it to rebuild the world:<br>> <br>> cd ~/cm3/scripts<br>> ./do-cm3-std.sh realclean<br>> ./do-cm3-std.sh buildship<br>> <br>> Assuming this succeeded then we can be pretty sure /usr/local/cm3/pkg/ <br>> cm3/TARGET/cm3 is good, so we can make it our default compiler by  <br>> replacing the original /usr/local/cm3/bin/cm3:<br>> <br>> cp $CM3 /usr/local/cm3/bin/cm3<br>> <br>> On Jun 23, 2007, at 2:38 PM, Mika Nystrom wrote:<br>> <br>> > Ok, I'm sorry if I seem a bit dimwitted in the morning like this,<br>> > but how exactly does one get started?  I wish there were a file called<br>> > "GETTING_STARTED" or something like that in scripts...<br>> ><br>> > My Mac is very slow so I switched to my FreeBSD/i386 system (which has<br>> > PM3 happily installed on it) and tried to install CM3 from scratch.<br>> > Here are the exact commands I typed.<br>> ><br>> ><br>> > rm -rf /usr/local/cm3/*<br>> ><br>> > cd ~/cm3-cvs<br>> > mkdir boot<br>> > cd boot<br>> > tar xzvf ../cm3-min-POSIX-FreeBSD4-d5.3.1-2005-10-05.tgz<br>> > ./cminstall<br>> ><br>> > # now I seem to have some kind of cm3 installed, /usr/local/cm3/bin/ <br>> > cm3<br>> ><br>> > cd cm3   # location of my CM3 checkout<br>> > cvs update -d .<br>> ><br>> > cd scripts<br>> > ./boot-cm3-with-m3.sh realclean<br>> > ./do-cm3-std.sh realclean<br>> ><br>> > ./upgrade.sh                      # fails here, libm3 not compiled<br>> > ./boot-cm3-with-m3.sh build       # builds cm3, but fails on  <br>> > cminstall, patternmatching not built<br>> ><br>> > ./do-cm3-std.sh build             # OK<br>> > ./do-cm3-std.sh buildship         # OK<br>> ><br>> > ./boot-cm3-with-m3.sh realclean   # start over<br>> > ./boot-cm3-with-m3.sh build       # OK<br>> > ./boot-cm3-with-m3.sh buildship   # OK<br>> ><br>> > ./do-cm3-std.sh realclean         # OK<br>> > ./do-cm3-std.sh build             # dies miserably... maybe the  <br>> > compiler can't handle the new libraries?<br>> ><br>> > ./install-cm3-compiler.sh upgrade # OK, new cm3 binary installed<br>> ><br>> > After all that, "game over."  I have a cm3 that segfaults.<br>> ><br>> > Text.i3: In function 'Text_I3':<br>> > Text.i3:81: internal compiler error: Segmentation fault<br>> > Please submit a full bug report,<br>> > with preprocessed source if appropriate.<br>> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.<br>> > compilation failed => not building library "libm3core.a"<br>> > Fatal Error: package build failed<br>> >  *** execution of  failed ***<br>> ><br>> > I can't seem to get either m3gdb or gdb to say anything reasonable<br>> > either.  ktrace shows nothing out of the ordinary.<br>> ><br>> > -----<br>> ><br>> > Meanwhile, my Mac got through "do-cm3-std.sh realclean" and<br>> > "do-cm3-std.sh buildship" but my compiles are still dying on the<br>> > same assertion tickled by ktok.  On that machine I have INSTALLROOT<br>> > set to ~/cm3, but hopefully that has nothing to do with it...<br>> ><br>> > -----<br>> ><br>> > Does do-cm3-std.sh realclean clean EVERYTHING?  If so my Mac should<br>> > really have a fresh setup.  The FreeBSD, I am not sure, maybe the<br>> > old binary version just doesn't work right?  Of course I could try<br>> > bootstrapping with PM3 as well... but really, there's an "approved"<br>> > process to get from a blank system, no?<br>> ><br>> >       Mika<br>> ><br>> ><br>> ><br>> ><br>> > Tony Hosking writes:<br>> >> That sounds like you forgot to execute "do-cm3-std.sh realclean"<br>> >> before initiating the build.  These sorts of errors sometimes arise<br>> >> if there are old build directories lying around.<br>> >><br>> >> On Jun 23, 2007, at 3:34 AM, Mika Nystrom wrote:<br>> >><br>> >>> Hello everyone,<br>> >>><br>> >>> I am in the process of trying to consolidate build systems for a<br>> >>> few software packages I am maintaining.  Currently, I am using an<br>> >>> old PM3 on FreeBSD4, an ancient PM3 (from Klagenfurt?) for Windows<br>> >>> (NT386GNU), and trying to get the latest CM3 from cvs up and  <br>> >>> compiling<br>> >>> things on PPC_DARWIN.  Ideally, I'd like to standardize everything<br>> >>> on the new PM3---mainly so that I can use pickles (and Network<br>> >>> Objects) across all three systems.  I'd also like to add Linux to<br>> >>> the mix.<br>> >>><br>> >>> It's natural for me to start with CM3 on Darwin, as there's no<br>> >>> alternative.  But I am getting some assertions failing.  Everything<br>> >>> in the CM3 distribution compiles fine, and I believe I have compiled<br>> >>> the libraries a few times (that is, including with themselves), and<br>> >>> updated the compiler, too (using boot-cm3-with-m3.sh).  I just cvs<br>> >>> updated tonight.<br>> >>><br>> >>> Here's what I'm running into:<br>> >>><br>> >>> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/CHP.t -o  <br>> >>> CHPTok.i3<br>> >>><br>> >>> ***<br>> >>> *** runtime error:<br>> >>> ***    <*ASSERT*> failed.<br>> >>> ***    file "../src/runtime/common/RTCollector.m3", line 2314<br>> >>> ***<br>> >>><br>> >>> Abort<br>> >>><br>> >>> Also:<br>> >>><br>> >>> /Users/mika/t/parserlib/ktok/PPC_DARWIN/tok ../src/PRS.t -o  <br>> >>> PRSTok.i3<br>> >>> Illegal instruction<br>> >>><br>> >>> As you can see, these things are coming from the caltech_parser.  I<br>> >> am using<br>> >>> our local version, but I don't think it is very different from what<br>> >>> is in the<br>> >>> CM3 tree.<br>> >>><br>> >>> Examining the first error (the failed assertion) more closely, I see<br>> >>> the following:<br>> >>><br>> >>> (gdb) list<br>> >>> 108         wr := FileWr.Open(Pathname.ReplaceExt(tp.out, "m3"));<br>> >>> 109       EXCEPT OSError.E =><br>> >>> 110         Debug.Error("Cannot open tok implementation output<br>> >>> file: " &<br>> >>> 111           Pathname.ReplaceExt(tp.out, "m3"));<br>> >>> 112       END;<br>> >>> 113       Wr.PutText(wr, subs.apply(Bundle.Get(Form,  <br>> >>> "tokform.m3")));<br>> >>> 114       Wr.Close(wr);<br>> >>> 115     END Main.<br>> >>> (gdb) where<br>> >>> #0  0x9004308c in kill ()<br>> >>> #1  0x9009fb3c in abort ()<br>> >>> #2  0x00096f50 in RTOS__Crash () at RTOS.m3:20<br>> >>> #3  0x0005bd40 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at<br>> >>> RTProcess.m3:65<br>> >>> #4  0x0008e4e0 in RTError__EndError (M3_AicXUJ_crash=1 '\001') at<br>> >>> RTError.m3:115<br>> >>> #5  0x0008e08c in RTError__MsgS (M3_AJWxb1_file=0xc63d8,<br>> >>> M3_AcxOUs_line=2314, M3_Bd56fi_msgA=0xca3d0,<br>> >>> M3_Bd56fi_msgB=0xcbe90, M3_Bd56fi_msgC=0xca3d0) at RTError.m3:40<br>> >>> #6  0x0008eb88 in RTException__Crash (M3_Cblw37_a=0xbfffee00,<br>> >>> M3_AicXUJ_raises=0 '\0', M3_AJWxb1_rte=0xcb538) at RTException.m3:79<br>> >>> #7  0x0008e74c in RTException__DefaultBackstop<br>> >>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at  <br>> >>> RTException.m3:39<br>> >>> #8  0x0008e614 in RTException__InvokeBackstop<br>> >>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at  <br>> >>> RTException.m3:25<br>> >>> #9  0x00095d04 in RTException__Raise (M3_Cblw37_act=0xbfffee00) at<br>> >>> RTExFrame.m3:29<br>> >>> #10 0x0008e840 in RTException__DefaultBackstop<br>> >>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at  <br>> >>> RTException.m3:47<br>> >>> #11 0x0008e614 in RTException__InvokeBackstop<br>> >>> (M3_Cblw37_a=0xbfffee00, M3_AicXUJ_raises=0 '\0') at  <br>> >>> RTException.m3:25<br>> >>> #12 0x00095d04 in RTException__Raise (M3_Cblw37_act=0xbfffee00) at<br>> >>> RTExFrame.m3:29<br>> >>> #13 0x00079740 in RTHooks__ReportFault (M3_AJWxb1_module=0xb3eb8,<br>> >>> M3_AcxOUs_info=74048) at RTHooks.m3:110<br>> >>> #14 0x0006ff4c in _m3_fault (M3_AcxOUs_arg=74048)<br>> >>> #15 0x0006bcf4 in RTHooks__CheckStoreTraced<br>> >>> (M3_Af40ku_ref=0xb2415c) at RTCollector.m3:2314<br>> >>> #16 0x000700e4 in ThreadPThread__InnerLockMutex<br>> >>> (M3_AYIbX3_m=0xb2415c, M3_BXP32l_self=0xb24014) at<br>> >>> ThreadPThread.m3:126<br>> >>> #17 0x000704d8 in ThreadPThread__LockMutex (M3_AYIbX3_m=0xb2415c)<br>> >>> at ThreadPThread.m3:153<br>> >>> #18 0x00019b24 in Wr__PutText (M3_BxxOH1_wr=0xb2415c,<br>> >>> M3_Bd56fi_t=0xb44d5c) at Wr.m3:93<br>> >>> #19 0x00003f74 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:113<br>> >>> #20 0x0005b1c4 in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at<br>> >>> RTLinker.m3:399<br>> >>> #21 0x00059f88 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at<br>> >>> RTLinker.m3:113<br>> >>> #22 0x0005a084 in RTLinker__AddUnit (M3_DjPxE5_b=0x3600) at<br>> >>> RTLinker.m3:122<br>> >>> #23 0x00001fac in main (argc=4, argv=0xbffffb24, envp=0xbffffb38)<br>> >>> at _m3main.mc:4<br>> >>> (gdb)<br>> >>><br>> >>> The second error:<br>> >>><br>> >>> Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/<br>> >>> operand.<br>> >>> 0x00b111ac in ?? ()<br>> >>> (gdb) where<br>> >>> #0  0x00b111ac in ?? ()<br>> >>> #1  0x0001214c in TextSubs__Apply (M3_CN69dV_self=0xb26450,<br>> >>> M3_Bd56fi_src=0xb21cec) at TextSubs.m3:63<br>> >>> #2  0x0005b1c4 in RTLinker__RunMainBody (M3_DjPxE3_m=0xad190) at<br>> >>> RTLinker.m3:399<br>> >>> #3  0x00059f88 in RTLinker__AddUnitI (M3_DjPxE3_m=0xad190) at<br>> >>> RTLinker.m3:113<br>> >>> #4  0x0005a084 in RTLinker__AddUnit (M3_DjPxE5_b=0x3600) at<br>> >>> RTLinker.m3:122<br>> >>> #5  0x00001fac in main (argc=4, argv=0xbffffb24, envp=0xbffffb38)<br>> >>> at _m3main.mc:4<br>> >>> (gdb) list<br>> >>> 58        BEGIN<br>> >>> 59          WHILE pos < textLen DO<br>> >>> 60            c := Text.GetChar(src, pos);<br>> >>> 61            IF c IN self.starts THEN<br>> >>> 62              (* S("analysing: " & Text.Sub(src, pos),<br>> >>> DebugLevel); *)<br>> >>> 63              iter := self.tbl.iterateOrdered();<br>> >>> 64              ind := pos;<br>> >>> 65              original := "";<br>> >>> 66              REPEAT<br>> >>> 67                INC(ind);<br>> >>> (gdb)<br>> >>><br>> >>> Any ideas what to look at?<br>> >>><br>> >>> I don't know if this is relevant:<br>> >>><br>> >>> [lapdog:~/t/cit_parse/PPC_DARWIN] mika% uname -a<br>> >>> Darwin lapdog.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30<br>> >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power<br>> >>> Macintosh powerpc<br>> >>> [lapdog:~/t/cit_parse/PPC_DARWIN] mika% gcc -v<br>> >>> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs<br>> >>> Thread model: posix<br>> >>> gcc version 3.3 20030304 (Apple Computer, Inc. build 1666)<br>> >>><br>> >>>      Mika<br>> >>><br>> >>> P.S. Am I correct in assuming that I can get CM3 to build on  <br>> >>> Windows?<br>> >>> I could switch to CM3 on Unix any time, of course, but I've never<br>> >>> had luck with it on Windows, which is why I am using the ancient<br>> >>> Klagenfurt PM3, which comes on 40-odd "floppies" and a .EXE that<br>> >>> unpacks them into C: (and installation instructions only in German).<br>> >>> If CM3 doesn't work on Windows, I am essentially wasting my time,<br>> >>> as the current project I am working on absolutely requires that the<br>> >>> software run on Windows 2003 Server (yes, it sucks, but what can<br>> >>> you do?)  The very old PM3 at least kind of hobbles along on this<br>> >>> platform---actually, better than that; it does Trestle natively<br>> >>> under Windows (no X required), at least on SOME Windows machines.<br>> >>><br>> >>> P.P.S. Sorry for all the postscripts, but is it true that the<br>> >>> build system has been changed so that building with overrides  <br>> >>> (cm3 -x)<br>> >>> requires having the compiler sources available?  It didn't use to<br>> >>> be that way, but I can't get Network Objects to work with overrides<br>> >>> now unless I have the sources available...  It's a bit of a pain<br>> >>> because it means that every user has to have the compiler sources,<br>> >>> or else ship everything, or was that not the intention?<br>                                         </body>
</html>