[M3devel] cm3 is broken

Jay jay.krell at cornell.edu
Sat Aug 22 23:50:42 CEST 2015 

Go back to one that is statically linked and upgrade from that?


upgrade.py nocleangcc doesn't take too long.


The backup must have, in general, cm3 cm3cg config libm3 m3core. 


We can relax the libm3 requirement I believe, but let's deal with that later separately.


 - Jay

On Aug 22, 2015, at 8:44 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> 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