[M3devel] cm3 is broken
Rodney M. Bates
rodney_bates at lcwb.coop
Sat Aug 22 17:44:04 CEST 2015
Going back several cm3 backups until I see a change, I have:
root at allegheny:/usr/local/cm3/bin# ldd cm3.bak22
linux-vdso.so.1 => (0x00007fff211fe000)
libsysutils.so.5 => /usr/local/cm3-uniboot/bin/./../lib/libsysutils.so.5 (0x00007f9fed722000)
libm3.so.5 => /usr/local/cm3-uniboot/bin/./../lib/libm3.so.5 (0x00007f9fed394000)
libm3core.so.5 => /usr/local/cm3-uniboot/bin/./../lib/libm3core.so.5 (0x00007f9fec8c2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9fec685000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9fec2bc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9febfb8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9fed957000)
root at allegheny:/usr/local/cm3/bin# ./cm3.bak22 -version
Critical Mass Modula-3 version d5.10.0
last updated: 2015-05-21
compiled: 2015-07-31 18:44:16
configuration: ./cm3.cfg
host: AMD64_LINUX
target: AMD64_LINUX
root at allegheny:/usr/local/cm3/bin# ldd cm3.bak21
linux-vdso.so.1 => (0x00007fffa47a7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7beee7d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7beec5f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7bee897000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7bef1a3000)
root at allegheny:/usr/local/cm3/bin# ./cm3.bak21 -version
Critical Mass Modula-3 version d5.10.0
last updated: 2015-05-21
compiled: 2015-06-04 14:24:48
configuration: ./cm3.cfg
host: AMD64_LINUX
target: AMD64_LINUX
So I compiled the change to dynamic between June 4 and July 31.
On 08/22/2015 05:00 AM, Jay K wrote:
> It works for me.
>
> Can you go back to a working install, maybe 5.8.6 with that slight config patch,
> run upgrade.py, add see what you get?
> Send the build log maybe?
>
>
> jair:python jay$ otool -L /cm3/bin/cm3
> /cm3/bin/cm3:
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
>
> jair:python jay$ /cm3/bin/cm3 -version
>
> Critical Mass Modula-3 version d5.10.0
> last updated: 2015-05-21
> compiled: 2015-08-22 09:57:19
> configuration: /cm3/bin/cm3.cfg
> host: I386_DARWIN
> target: I386_DARWIN
>
>
> On most other systems, use ldd.
> On Windows use link /dump /imports or link /dump /dependents.
>
>
> - Jay
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at purdue.edu; rodney.m.bates at acm.org
> Date: Sat, 22 Aug 2015 09:28:01 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] cm3 is broken
>
> This was not meant to change and I haven't seen that it did change.
> Maybe my cleaning up of the config files. I'll check.
>
>
> I understand the risks well. I have a potential plan to change it. But that is another matter.
>
> You still need to backup libm3/m3core with cm3 -- so that cm3 can build anything that works.
>
> The wrong uprade sequence still breaks cm3. That is at it should be.
>
>
> Tangentially, here is my plan:
> The upgrade process must be "to the side and switch all at once", not "in place".
> It might go over and back though -- i.e. cm3 can move a new cm3, m3core, and libm3 all
> into the install in tight sequence (not atomically). The trick on NT would be to unmap the
> executable, and avoid returning to it -- some sort of "continuation passing style",
> possibly off into a little bit of C++, whose main task would be to move a few files
> and then exit.
>
>
> That'd still leave all the platforms to test on to see if a running executable can be replaced.
> esp. including AIX.
>
>
> Perhaps it isn't worth it. I have at least endeavored to priortize everything else ahead of this
> and just leave it as an idea/plan that I don't get to
>
> - Jay
>
>
>
>
> > Subject: Re: [M3devel] cm3 is broken
> > From: hosking at purdue.edu
> > Date: Sat, 22 Aug 2015 06:48:15 +1000
> > CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> > To: rodney.m.bates at acm.org
> >
> > That is a regression.
> >
> > Sent from my iPad
> >
> > > On 22 Aug 2015, at 2:38 am, Rodney M. Bates <rodney_bates at lcwb.coop> wrote:
> > >
> > >
> > >
> > >> On 08/20/2015 06:32 PM, Antony Hosking wrote:
> > >> cm3 should build with static link to m3core so as to allow backup as you describe.
> > >> Did this change recently?
> > >
> > > Apparently it is now dynamic, as I see libm3core.so.5 in the backtrace. Also, setting
> > > a breakpoint at one of these places gives:
> > >
> > >
> > > (m3gdb) b RTExFrame.m3:175
> > > No source file named RTExFrame.m3.
> > > Make breakpoint pending on future shared library load? (y or [n]) y
> > > Breakpoint 1 (RTExFrame.m3:175) pending.
> > > (m3gdb) run
> > >
> > > ........
> > >
> > > Breakpoint 2 at 0x7f446c889043: file ../src/runtime/ex_frame/RTExFrame.m3, line 175.
> > > Pending breakpoint "RTExFrame.m3:175" resolved
> > >
> > >
> > >
> > >>
> > >>> On Aug 21, 2015, at 3:19 AM, Jay <jay.krell at cornell.edu> wrote:
> > >>>
> > >>> Upgrade is failing because cm3 is already broken. I can see about making the error clearer.
> > >>>
> > >>>
> > >>> I often upgrade.py nocleangcc to speed it up.
> > >>>
> > >>>
> > >>> Right, backup must include libm3 m3core cm3cg cm3 config. See capture-min or capture-boot, I think I settled on capture-min.
> > >>>
> > >>>
> > >>> m3cc either needs to keep the "front" tag or the scripts need to mention it explicitly. You can't safely always skip it.
> > >>>
> > >>>
> > >>> Do you have recourse?
> > >>> Old release maybe? (Be sure to edit the 5.8.6 config to avoid new cm3cg.)
> > >>>
> > >>> - Jay
> > >>>
> > >>>> On Aug 20, 2015, at 8:44 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On 08/19/2015 06:57 PM, Jay K wrote:
> > >>>>> Did you upgrade.py? (or possibly upgrade.sh?)
> > >>>>
> > >>>> upgrade.py does this:
> > >>>>
> > >>>> rodney at allegheny:~/proj/m3/git/cm3/scripts/python$ python upgrade.py
> > >>>> Traceback (most recent call last):
> > >>>> File "upgrade.py", line 4, in <module>
> > >>>> import pylib
> > >>>> File "/home/rodney/proj/m3/git/cm3/scripts/python/pylib.py", line 656, in <module>
> > >>>> if Target.startswith("NT386"):
> > >>>> AttributeError: 'NoneType' object has no attribute 'startswith'
> > >>>>
> > >>>> I did 'do-cm3-front.sh' buildship' and 'install-cm3-compiler.sh upgrade',
> > >>>> with front removed from the m3cc line in pkginfo.txt, since there were no
> > >>>> changes to it, and it takes longer to compile than everything else combined.
> > >>>>
> > >>>> upgrade.sh now segfaults after cleaning things out, but that is no doubt just
> > >>>> the now-broken cm3.
> > >>>>
> > >>>> I always make backup copies of cm3 & cm3cg in /usr/local/cm3/bin before installing
> > >>>> a compiler, but restoring what I had before does not fix the problem. I suppose
> > >>>> it is in m3core, which I guess I need to add to my backup habit.
> > >>>>
> > >>>>> I changed the cm3/m3core interface, so you must do the ugprade in the usual proper order.
> > >>>>>
> > >>>>> I run upgrade.py frequently and recommend it.
> > >>>>>
> > >>>>> - Jay
> > >>>>>
> > >>>>>
> > >>>>>> Date: Wed, 19 Aug 2015 17:20:25 -0500
> > >>>>>> From: rodney_bates at lcwb.coop
> > >>>>>> To: m3devel at elegosoft.com
> > >>>>>> Subject: [M3devel] cm3 is broken
> > >>>>>>
> > >>>>>> 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
> > >>>>
> > >>>> --
> > >>>> 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
--
Rodney Bates
rodney.m.bates at acm.org
More information about the M3devel
mailing list