[M3devel] cm3 is broken: More info

[Jay]

On the other matter -- Cerrno.GetErrno() is thread safe.

It ends up as a function that accesses a thread local. At least on Windows and surely that is the only logical approach. 

It is still a bad design. Thread locals don't make things all better. They are still "fragile" (easy to change by accident), slow, and don't provide for reentrance.

 - Jay

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

> 
> 
> 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