<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Rodney, no this doesn't make sense.<BR>The new runtime is never expected to work with an old compiler.<BR>No mix and match is required to work.<BR>But very few changes get made here, so the mix & match often does work, almost always.<BR> <BR> <BR>upgrade.py does build the compiler twice for this reason. You are right.<BR>And you are correct as to where it is set.<BR>The first uses the old runtime itself, the second uses the new runtime itself.<BR>Removing the assert will not fix it.<BR> <BR>Sorry, I'm late in:<BR> 1) re-bootstrapping from 5.8.6 -- though I did this multiple times already<BR> While I iterated a bunch on Darwin, I was able to upgrade Linux and Solaris (multiple targets)<BR> in one easy step each. I will go back to 5.8.6 and try again to be extra extra certain.<BR> <BR> <BR> 2) getting you a new min to start from, which will work and not really prove anything.<BR> <BR>Can you go back to 5.8.6, edit its config to avoid using the old cm3cg, run upgrade.py, and send <BR>the full log?<BR> <BR>I will also go back to 5.8.6 maybe tonight and upgrade.py.<BR>I understand that, at least, is required to work.<BR> <BR> - Jay<br><br> <BR><div>> Date: Mon, 24 Aug 2015 21:08:09 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] cm3 is broken: More info<br>> <br>> Jay, I have looked into this, and I think there is a bootstrap barrier. The ASSERT at<br>> m3-libs/m3core/src/runtime/ex_frame/RTExFrame.m3:175, procedure InvokeHandler, fails with field<br>> jmpbuf of an exception frame being NIL. The only place I find that this field could be<br>> set is by compiler-generated code, generated at m3-sys/m3front/src/misc/Marker.m3:234,<br>> in procedure CaptureState.<br>> <br>> From a version without this rework, it will require compiling the compiler twice, once to<br>> get a compiler that would generate this code, and again to get a compiler that executes<br>> it when run. You are saying the middle compiler legitimately raises and catches an exception,<br>> in order to run, so we can't get past this step. And it could do that in other places too.<br>> <br>> I am guessing you have re-bootstrapped your compiler through more than one intermediate state<br>> of source code, so you don't get this problem. But it has to work somehow from the original version,<br>> for everybody else.<br>> <br>> Will it work with the new compiler-generated code but old runtime? Seems like a long shot.<br>> <br>> On 08/22/2015 06:37 PM, Jay wrote:<br>> > Hm. Something is not right. Can I build you an AMD64_LINUX min dist and you try upgrading from that? That is NOT my proposed general path forward, but a troubleshooting move.<br>> ><br>> ><br>> > I upgraded multiple installations on multiple targets.<br>> > I'll try again from 5.8.6.<br>> ><br>> ><br>> > I suggest upgrade also check for the bad dynamic linking.<br>> ><br>> ><br>> > Anyone else able/unable to upgrade?<br>> ><br>> > - Jay<br>> ><br>> > On Aug 22, 2015, at 2:54 PM, "Rodney M. Bates" <rodney_bates@lcwb.coop> wrote:<br>> ><br>> >><br>> >><br>> >> On 08/22/2015 12:26 PM, Jay K wrote:<br>> >>> It is normal to get an exception here -- I think cm3 looks in current working directory..not great but that's how it is.<br>> >>> That is how I know my stuff is working -- exceptions are a normal part of operation. If you break them, you know it quickly.<br>> >>><br>> >>><br>> >>> Anyway, you need to go back to a working cm3 + cm3cg + config + libm3 + m3core and run upgrade.py.<br>> >>> Nothing else is going to work. (ok, maybe upgrade.sh works, but I didn't try it.)<br>> >><br>> >> OK, I did that. Got a working cm3 going, backed up my source/build directories and install<br>> >> directory, ran scripts/python/upgrade.py. Right after it (as well as I can read it) installed<br>> >> cm3, there is a segfault, and things after that look bad. A brand new cm3 is in my<br>> >> /usr/local/cm3/bin, and it has the same symptoms as with my previous build method, when run<br>> >> independently.<br>> >><br>> >> After a good lot of successful-looking output, I get:<br>> >><br>> >> new source -> compiling LLGen.i3<br>> >> new source -> compiling LLGen.m3<br>> >> new source -> compiling Version.i3<br>> >> new source -> compiling M3Backend.i3<br>> >> new source -> compiling Arg.i3<br>> >> new source -> compiling Utils.i3<br>> >> new source -> compiling Msg.i3<br>> >> new source -> compiling M3Backend.m3<br>> >> new source -> compiling UtilsPosix.m3<br>> >> new source -> compiling Arg.m3<br>> >> new source -> compiling M3Loc.i3<br>> >> new source -> compiling M3Unit.i3<br>> >> new source -> compiling Builder.i3<br>> >> new source -> compiling M3Options.i3<br>> >> new source -> compiling WebFile.i3<br>> >> new source -> compiling Dirs.i3<br>> >> new source -> compiling Builder.m3<br>> >> new source -> compiling Dirs.m3<br>> >> new source -> compiling M3Build.i3<br>> >> new source -> compiling M3Build.m3<br>> >> new source -> compiling M3Loc.m3<br>> >> new source -> compiling M3Options.m3<br>> >> new source -> compiling M3Unit.m3<br>> >> new source -> compiling Makefile.i3<br>> >> new source -> compiling Makefile.m3<br>> >> new source -> compiling Msg.m3<br>> >> new source -> compiling Utils.m3<br>> >> new source -> compiling WebFile.m3<br>> >> new source -> compiling Main.m3<br>> >> "../src/Main.m3", line 231: warning: potentially unhandled exception: Wr.Failure<br>> >> 1 warning encountered<br>> >> new source -> compiling cm3unix.c<br>> >> new exporters -> recompiling Utils.i3<br>> >> -> linking cm3<br>> >> --- shipping from AMD64_LINUX ---<br>> >><br>> >> . => /usr/local/cm3/pkg/cm3/AMD64_LINUX<br>> >> .M3EXPORTS .M3WEB<br>> >> ../AMD64_LINUX => /usr/local/cm3/pkg/cm3/AMD64_LINUX<br>> >> cm3unix.c Version.i3<br>> >> ../src => /usr/local/cm3/pkg/cm3/src<br>> >> M3Backend.i3 M3Backend.m3 UtilsPosix.m3 Arg.i3<br>> >> Arg.m3 Builder.m3 Builder.i3 Dirs.i3<br>> >> Dirs.m3 M3Build.m3 M3Build.i3 M3Loc.m3<br>> >> M3Loc.i3 M3Options.m3 M3Options.i3 M3Unit.i3<br>> >> M3Unit.m3 Makefile.i3 Makefile.m3 Msg.i3<br>> >> Msg.m3 Utils.m3 Utils.i3 WebFile.i3<br>> >> WebFile.m3 Main.m3<br>> >> ../src/llvmdummy => /usr/local/cm3/pkg/cm3/src/llvmdummy<br>> >> LLGen.m3 LLGen.i3<br>> >> . => /usr/local/cm3/bin<br>> >> cm3<br>> >> . => /usr/local/cm3/man/man1<br>> >> cm3.1<br>> >> . => /usr/local/cm3/man/man7<br>> >> m3makefile.7<br>> >> Segmentation fault (core dumped)<br>> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>> >> -ship -DROOT=/home/rodney/proj/m3/git/cm3 +++<br>> >> ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3objfile done<br>> >><br>> >> == package /home/rodney/proj/m3/git/cm3/m3-sys/m3linker ==<br>> >><br>> >> +++ /usr/local/cm3/bin/cm3 -build -DROOT=/home/rodney/proj/m3/git/cm3 +++<br>> >> ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3linker done<br>> >><br>> >><br>> >> -------------------------------------------------------------------------------------<br>> >> several more almost same sequences as m3linker omitted, for m3back, m3cggen, m3quake,<br>> >> m3front, m3cgcat, m3bundle, mklib, cm3 again. Then, for m3cc:<br>> >> -------------------------------------------------------------------------------------<br>> >><br>> >><br>> >> /home/rodney/proj/m3/git/cm3/m3-sys/m3cggen/AMD64_LINUX/m3cggen > /home/rodney/proj/m3/git/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h<br>> >> == package /home/rodney/proj/m3/git/cm3/m3-sys/m3cc ==<br>> >><br>> >> +++ /usr/local/cm3/bin/cm3 -build -DROOT=/home/rodney/proj/m3/git/cm3 +++<br>> >> *** execution of [<function _BuildGlobalFunction at 0x7fb94d704a28>, <function _ShipFunction at 0x7fb94d704aa0>] failed ***<br>> >><br>> >><br>> >><br>> >><br>> >><br>> >><br>> >><br>> >><br>> >><br>> >>> The interface here between cm3's generated code/data and m3core has changed.<br>> >>> You cannot mix them. It will fail.<br>> >>><br>> >>><br>> >>> - Jay<br>> >>><br>> >>><br>> >>><br>> >>><br>> >>>> Date: Sat, 22 Aug 2015 11:41:14 -0500<br>> >>>> From: rodney_bates@lcwb.coop<br>> >>>> To: m3devel@elegosoft.com; jay.krell@cornell.edu<br>> >>>> Subject: Re: [M3devel] cm3 is broken: More info<br>> >>>><br>> >>>><br>> >>>><br>> >>>> On 08/22/2015 11:33 AM, Rodney M. Bates wrote:<br>> >>>>> There are at least two problems. The runaway recursion happens in RTExFrame.m3:175<br>> >>>>><br>> >>>>> PROCEDURE InvokeHandler (f: Frame; READONLY a: RT0.RaiseActivation) RAISES ANY =<br>> >>>>> VAR p := LOOPHOLE (f, PF1);<br>> >>>>> BEGIN<br>> >>>>> IF DEBUG THEN<br>> >>>>> PutExcept ("INVOKE HANDLER", a);<br>> >>>>> RTIO.PutText (" frame="); RTIO.PutAddr (f);<br>> >>>>> RTIO.PutText (" class="); RTIO.PutInt (f.class);<br>> >>>>> RTIO.PutText ("\n");<br>> >>>>> RTIO.Flush ();<br>> >>>>> END;<br>> >>>>> RTThread.SetCurrentHandlers (f.next); (* cut to the new handler *)<br>> >>>>> p.info := a; (* copy the exception to the new frame *)<br>> >>>>> <* ASSERT p.jmpbuf # NIL *><br>> >>>>> ------^^^^^^^^^^^^^^^^^^^^^^^^^^^ This assertion fails and tries to raise another fault.<br>> >>>>> Csetjmp.ulongjmp (p.jmpbuf, 1); (* and jump... *)<br>> >>>>> RAISE OUCH;<br>> >>>>> END InvokeHandler;<br>> >>>>><br>> >>>>> (m3gdb) frame 0<br>> >>>>> #0 InvokeHandler (f=16_00007fff509f4af0, a=<br>> >>>>> RECORD exception = 16_00007ff696883aa0; arg = 16_00000000013e4ae8; module = 16_00007ff6968a3060; line = 50; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:175<br>> >>>>> 175 <* ASSERT p.jmpbuf # NIL *><br>> >>>>> (m3gdb) p p.jmpbuf<br>> >>>>> $31 = NIL<br>> >>>>> --------^^^<br>> >>>>> (m3gdb)<br>> >>>>><br>> >>>>><br>> >>>>> The original problem starts in FSPosix.m3:328, when cm3.cfg is not found:<br>> >>>>><br>> >>>>> PROCEDURE Status(pn: Pathname.T): File.Status RAISES {OSError.E} =<br>> >>>>> VAR status: File.Status; fname := M3toC.SharedTtoS(pn);<br>> >>>>> BEGIN<br>> >>>>> IF CStatus(fname, status) < 0 THEN Fail(pn, fname); END;<br>> >>>>> ---------^^^^^^^^^^^^^^^^^^^^^^<br>> >>>>> M3toC.FreeSharedS(pn, fname);<br>> >>>>> RETURN status<br>> >>>>> END Status;<br>> >>>>><br>> >>>>> (m3gdb)<br>> >>>>> #6 0x00007ff696593c14 in Status (pn=16_00000000013e4ac0, _result=RECORD type = 16_0000000000000001; modificationTime = ; size = 1; END)<br>> >>>>> at ../src/os/POSIX/FSPosix.m3:328<br>> >>>>> 328 IF CStatus(fname, status) < 0 THEN Fail(pn, fname); END;<br>> >>>>> (m3gdb) p pn<br>> >>>>> $30 = (*16_00000000013e4ac0*) "./cm3.cfg"<br>> >>>>> --------------------------------^^^^^^^^^^^<br>> >>>>> (m3gdb)<br>> >>>>><br>> >>>>> I have a cm3.cfg beside cm3, where it should be. Could the current directory be wrong?<br>> >>>><br>> >>>> A bit more info:<br>> >>>><br>> >>>> (m3gdb) down<br>> >>>> #6 0x00007ff696593c14 in Status (pn=16_00000000013e4ac0, _result=RECORD type = 16_0000000000000001; modificationTime = ; size = 1; END)<br>> >>>> at ../src/os/POSIX/FSPosix.m3:328<br>> >>>> 328 IF CStatus(fname, status) < 0 THEN Fail(pn, fname); END;<br>> >>>> (m3gdb) p Process.GetWorkingDirectory()<br>> >>>> $32 = (*16_0000000001420170*) "/home/rodney/proj/m3/exp/trytemp/src"<br>> >>>> --------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>> >>>> (m3gdb)<br>> >>>><br>> >>>> This is where I ran cm3 from.<br>> >>>><br>> >>>><br>> >>>>><br>> >>>>> Also, I notice one other thing, that probably isn't part of this problem, but maybe needs<br>> >>>>> to be fixed. Fail, when called from Status, uses Cerrno.GetErrno in a separate call,<br>> >>>>> after the failing CStatus above. Obviously not thread safe. Does it matter here?<br>> >>>>> As I recall from many years ago, there was a change in C library that provided a thread<br>> >>>>> safe alternative to this, and I even think I had to change something in pm3 or SRC to<br>> >>>>> adapt to it. Do we care?<br>> >>>>><br>> >>>>> PROCEDURE Fail(p: Pathname.T; f: Ctypes.char_star) RAISES {OSError.E} =<br>> >>>>> VAR err := Cerrno.GetErrno();<br>> >>>>> ---------------^^^^^^^^^^^^^^^^^<br>> >>>>> BEGIN<br>> >>>>> M3toC.FreeSharedS(p, f);<br>> >>>>> OSErrorPosix.Raise0(err);<br>> >>>>> END Fail;<br>> >>>>><br>> >>>>><br>> >>>>><br>> >>>>> On 08/19/2015 05:20 PM, Rodney M. Bates wrote:<br>> >>>>>> As of a recent pull from modula3-cm3, done around 16:00 CDT, cm3 is going into<br>> >>>>>> runaway recursion trying to report a fault. This happens immediately upon<br>> >>>>>> running it, before it produces any output.<br>> >>>>>><br>> >>>>>> Here is one cycle of the backtrace:<br>> >>>>>><br>> >>>>>> #1745 0x00007fd9b0b0d935 in _m3_fault (arg=5600) from /usr/local/cm3-uniboot/bin/../lib/libm3core.so.5<br>> >>>>>> #1746 0x00007fd9b0b0d05d in InvokeHandler (f=16_00007fff488bcc20, a=<br>> >>>>>> RECORD exception = 16_00007fd9b0d4b780; arg = 16_000000000000001d; module = 16_00007fd9b0d62d40; line = 14; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:175<br>> >>>>>> #1747 0x00007fd9b0b0cef1 in ResumeRaise (a=<br>> >>>>>> RECORD exception = 16_00007fd9b0d4b780; arg = 16_000000000000001d; module = 16_00007fd9b0d62d40; line = 14; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:145<br>> >>>>>> #1748 0x00007fd9b0b0ccfe in Raise (act=<br>> >>>>>> RECORD exception = 16_00007fd9b0d4b780; arg = 16_000000000000001d; module = 16_00007fd9b0d62d40; line = 14; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:91<br>> >>>>>> #1749 0x00007fd9b0ae9693 in Raise (ex=16_00007fd9b0d4b780, arg=16_000000000000001d, module=16_00007fd9b0d62d40, line=14)<br>> >>>>>> at ../src/runtime/common/RTHooks.m3:79<br>> >>>>>> #1750 0x00007fd9b0ae9951 in Self () at ../src/runtime/common/RuntimeError.m3:14<br>> >>>>>> #1751 0x00007fd9b0ae96ef in ReportFault (module=16_00007fd9b0d6a520, info=5600) at ../src/runtime/common/RTHooks.m3:98<br>> >>>>>> #1752 0x00007fd9b0b0d935 in _m3_fault (arg=5600) from /usr/local/cm3-uniboot/bin/../lib/libm3core.so.5<br>> >>>>>><br>> >>>>>> So far, I haven't had the patience to keep hitting return until I get to the bottom of it.<br>> >>>>>><br>> >>>>><br>> >>>><br>> >>>> --<br>> >>>> Rodney Bates<br>> >>>> rodney.m.bates@acm.org<br>> >>>> _______________________________________________<br>> >>>> M3devel mailing list<br>> >>>> M3devel@elegosoft.com<br>> >>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> >>><br>> >>><br>> >>> _______________________________________________<br>> >>> M3devel mailing list<br>> >>> M3devel@elegosoft.com<br>> >>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> >><br>> >> --<br>> >> Rodney Bates<br>> >> rodney.m.bates@acm.org<br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>