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