[M3devel] recent problems?

[Tony Hosking]

Keep up the good work Jay!

On 17 Mar 2009, at 13:47, Jay wrote:

> I'm making the system more safe, not less.
>
>
> The previous methodology was tedious, error prone, and didn't get  
> any sort of checking.
>
>
> Whatever was declared in the *.i3 files was presumed correct.
>
>
> The linkage from the next layer to this layer gets the same amount  
> of checking as it used.
>
>
> The link you point to shows people fixing things the same way as I  
> am making them.
>
>
> unix/*.i3 must use <*EXTERNAL*> to declare C functions.
> That is what it did. That is what it does.
> Extend this out slightly to m3core/libm3.
>  Same thing.
> The difference is whether or not those C functions are implemented  
> right there, once, plain to see that they match the <*EXTERNAL*>  
> declarations, or whether they are in a per-platform /usr/include and  
> source tree somewhere, with tedious and error prone and per-platform  
> verification as to if they are correct. As well as copy/pasting  
> where there the "API" might be a macro.
>
>
> Really, I am making the system more safe, not less.
> There is no loss in checking but there is more obvious correctness  
> by human inspection in what must be unsafe, one way or another.
>
>
> The result is also more portable.
>
>
>  - Jay
>
> Date: Mon, 16 Mar 2009 17:14:35 -0700
> From: dabenavidesd at yahoo.es
> To: hosking at cs.purdue.edu; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] recent problems?
>
> Hi all:
> well, I know more about the kind of work done recently, which I can  
> not just say is unsafe, but putting a layer of C code that obviously  
> is dependent of each Linux/Unix, I guess in the past this is not  
> always true, but having each Linux it's own headers and different  
> implementations makes more unstable the system.
> Besides the type checking made by C Compiler is not checked at link  
> time, in contrast of Modula-3 that type checks whenever interfaces  
> are changed and checks on link time.
> So if you put change in your C code doesn't mean that Modula-3 will  
> catch common silly but common true errors, like buffer overflows  
> that if not checked at run time will crash (almost always) at  
> runtime of a safe program, and it will not be safe (hidden code is  
> beyond the Modula-3 compiler).
> I strongly support simplifying and factoring as much as possible,  
> but try to use what is there in Modula-3, not re-implementing in  
> another Language if possible at all. I know but even more, the idea  
> of having linking with C code on the kernel system calls allows to  
> protect from so called side effects of Kernel code. Memory  
> protection is exhausted here.
> But when using true library user space system calls, this puts in a  
> dangerous side the untrusted code. Here I reclaim again not using  
> more that true system calls. I see that this started to be harder  
> with AMD64 or x86_64 current platforms, so further development may  
> be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html 
>  about ezm3 related problems, is this supposed to be handled in Cm3  
> like the same they did?
> Jay and all seem to do the better job they can, but I don't want to  
> miss the opportunity to say this if I may. I will tell you later  
> more about the type system If this it is useful to be said.
>
> Thanks in advance
>
> --- El lun, 16/3/09, Jay <jay.krell at cornell.edu> escribió:
> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] recent problems?
> Para: "Tony" <hosking at cs.purdue.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 16 marzo, 2009 3:55
>
> It's ok on LINUXLIBC6 with the "new headers" but
> I believe PPC_DARWIN problem caused by them so
> backed out pending debugging.
> This one looks easy to solve, though my time
> is scarser next week or two.
>
> I should have maybe considered:
>   "new headers" used on a number of Linux systems already
>   but no Darwin systems yet
>
>  - Jay
>
>
> ----------------------------------------
> > From: hosking at cs.purdue.edu
> > To: jay.krell at cornell.edu
> > Date: Tue, 17 Mar 2009 01:54:34 +1100
> > CC:
>  m3devel at elegosoft.com
> > Subject: Re: [M3devel] recent problems?
> >
> > This is worrying as it seems some level of instability has been
> > introduced by recent changes. mentor used to be fine.
> >
> > On 17 Mar 2009, at 00:16, Jay wrote:
> >
> >>
> >> mklib seems ok now, having started over with a new checkout, new
> >> build.
> >> Strange considering what I had already tried, this problem had been
> >> plaguing me over a week.
> >>
> >>
> >> stubgen doesn't hang with 1.5, will try 1.7 again/later.
> >>
> >>
> >> But formsedit still crashes during startup intermittently,
> >> and Cygwin X apps hang at startup.
> >> ugh.
> >> I know, I probably caused whatever problem..
> >>
> >>
> >> - Jay
> >>
> >>
> >>
> >> ----------------------------------------
> >>> From:
>  jay.krell at cornell.edu
> >>> To: hosking at cs.purdue.edu
> >>> CC: m3devel at elegosoft.com
> >>> Subject: RE: [M3devel] recent problems?
> >>> Date: Mon, 16 Mar 2009 08:57:40 +0000
> >>>
> >>>
> >>> Thanks.
> >>>
> >>>
> >>> Here is another one.
> >>> I found this testing moving PPC_DARWIN to "my headers".
> >>> formsedit crashes during startup roughly more than
> >>> half the times I start up, but not every time.
> >>> The stack is always the same.
> >>> I'll test it without my change.
> >>> I think it'll happen either way, but I'll see.
> >>> Yes, it recurs without my change, though I double
> >>> check that my change is really undone.
> >>> I'll have to dig into this.
> >>>
> >>>
> >>> How does one get the code from CVS corresponding to a
>  date?
> >>> cvs upd -D ?
> >>> I'll try that or something, see if I can find when things
> worked.
> >>>
> >>>
> >>> I should also be able to try the mklib crashing scenario
> >>> on other platforms. It normally doesn't run on other
> platforms.
> >>>
> >>>
> >>> stubgen..if I'm ambitious, I can run in a loop on another
> platform.
> >>> But I think just moving Cygwin off of pthreads will
> "fix" it
> >>> and provide a cleaner base (not due to pthreads, but the Cygwin
> >>> stuff).
> >>>
> >>>
> >>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
> >>> [Switching to process 19583 thread 0x2643]
> >>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows
> >>> (M3_Ao3CED_v=0x1f1eef4) at
>  ../src/lego/POSIX/Sc
> >>> rollerVBTClass.m3:325
> >>> 325 VBT.PaintTint(v, r, v.shadow.bg);
> >>> (gdb) bt
> >>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows
> >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI
> >>> X/ScrollerVBTClass.m3:325
> >>> #1 0x0031766c in ScrollerVBTClass__PaintView
> >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV
> >>> BTClass.m3:292
> >>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4,
> >>> M3_A0Kbc5_rgn=0xf0284778) at ../
> >>> src/lego/POSIX/ScrollerVBTClass.m3:693
> >>> #3 0x0031a590 in ScrollerVBTClass__Redisplay
> >>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV
> >>> BTClass.m3:706
> >>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at
> ../
> >>> src/vbt/VBTClass.m3:367
> >>>
>  #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652
> >>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/
> >>> VBTRep.m3:601
> >>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../
> >>> src/vbt/VBTRep.m3:606
> >>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940)
> >>> at ../src/thread/PTHREAD/ThreadP
> >>> Thread.m3:531
> >>> #9 0x0132fb58 in ThreadPThread__ThreadBase
> >>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr
> >>> eadPThread.m3:508
> >>> #10 0x9002b908 in _pthread_body ()
> >>> (gdb)
> >>>
> >>>
> >>>
> >>> - Jay
> >>>
> >>>
> >>>
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> To:
>  jay.krell at cornell.edu
> >>>> Date: Mon, 16 Mar 2009 08:10:05 +1100
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] recent problems?
> >>>>
> >>>> You might have structure sizes wrong and your stack will get
> shifted
> >>>> around as the command line changes length. You get some data
> in a
> >>>> structure wrong and then hit the wrong stack org and you might
> see
> >>>> problems like this.
> >>>>
> >>>> I am not running things totally off of the head, so if the
> problem
> >>>> was
> >>>> introduced recently it might only now be seen.
> >>>>
> >>>> On 16 Mar 2009, at 06:15, Jay wrote:
> >>>>
> >>>>>
> >>>>> I'm seeing some problems lately. Maybe it is just me.
> >>>>> Some of them I've had over
>  a week (ie: before my
> (most) recent
> >>>>> changes),
> >>>>> some of them even if recently appeared I verified without
> my (most)
> >>>>> recent changes.
> >>>>>
> >>>>> On Cygwin 1.5, mklib always crashes. I haven't been
> able to debug
> >>>>> it.
> >>>>> This has been over a week.
> >>>>> I've had to stop using Cygwin for Modula-3 development
> on this
> >>>>> machine.
> >>>>> I have a good repro but hadn't had luck yet debugging
> it.
> >>>>> Basically if I shorten the mklib command line (in the
> response
> >>>>> file) substantially, no crash.
> >>>>> There is a cut off somewhere.
> >>>>>
> >>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but
> not always
> >>>>>
>  hangs.
> >>>>> It hangs nowhere else.
> >>>>> This I verified occured without my recent changes.
> >>>>> I only just in the past few days tried Cygwin 1.7.
> >>>>> mklib works fine here.
> >>>>> Of course since this is somewhat intermittent, maybe it
> isn't a new
> >>>>> problem.
> >>>>>
> >>>>> I've only tried Cygwin 1.5 and 1.7 on one machine
> each, separate
> >>>>> machines,
> >>>>> though they do coexist ok on one machine.
> >>>>> 1.7 seemed much faster (on an unimpressive machine),
> though 1.7
> >>>>> binares
> >>>>> apparently don't run on 1.5 -- at least not if they
> use assert().
> >>>>> 1.7 is a recent past or future release, a long time in the
> works,
> >>>>> drops Win9x support, lots of good
>  sounding changes.
> >>>>>
> >>>>> I should run m3tests more, maybe they will reveal the
> crash or the
> >>>>> hang as well.
> >>>>>
> >>>>> On LINUXLIBC6 on one machine stubgen was crashing at least
> in one
> >>>>> directory.
> >>>>> But I think this stopped happening.
> >>>>>
> >>>>> Cygwin being broken pushes me to other platforms more,
> probably a
> >>>>> good thing.
> >>>>> I'm loathe to debug the hang. When it occurs I
> can't see any stacks
> >>>>> in gdb. I can see in strace..
> >>>>> I think we are waiting for all the threads to suspend
> themselves.
> >>>>> I'll probably try moving back to Win32 threads and see
> if it clears
> >>>>> up.
> >>>>> I know that's not
>  great.
> >>>>> There isn't a clear implied question and I know I
> should/need to
> >>>>> look into these,
> >>>>> but I also thought I shouldn't keep this to myself. I
> also
> >>>>> understand the philosophy
> >>>>> of stopping changes when there are problems, to stop
> further
> >>>>> damage, but, of course,
> >>>>> I'm very confident in my changes (always..), have been
> testing them
> >>>>> on other platforms,
> >>>>> and looking them over extra extra since I know of these
> other
> >>>>> problems.
> >>>>>
> >>>>> I'm not sure any problem on Cygwin is worrisome
> really.
> >>>>> I think the underlying code is kind of gnarly and I
> don't think
> >>>>> anyone uses this platform, though people asked for
>  it.
> >>>>> But I did have a crash on LINUXLIBC6.
> >>>>>
> >>>>> - Jay
> >>>>
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090317/b5cfa527/attachment-0002.html>