<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>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.<br>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.<br>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).<br>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.<br>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?<br>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.<br><br>Thanks in
 advance<br><br>--- El <b>lun, 16/3/09, Jay <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">De: Jay <jay.krell@cornell.edu><br>Asunto: Re: [M3devel] recent problems?<br>Para: "Tony" <hosking@cs.purdue.edu><br>CC: "m3devel" <m3devel@elegosoft.com><br>Fecha: lunes, 16 marzo, 2009 3:55<br><br><pre>It's ok on LINUXLIBC6 with the "new headers" but<br>I believe PPC_DARWIN problem caused by them so <br>backed out pending debugging.<br>This one looks easy to solve, though my time<br>is scarser next week or two.<br> <br>I should have maybe considered:<br>  "new headers" used on a number of Linux systems already <br>  but no Darwin systems yet <br> <br> - Jay<br><br><br>----------------------------------------<br>> From: hosking@cs.purdue.edu<br>> To: jay.krell@cornell.edu<br>> Date: Tue, 17 Mar 2009 01:54:34 +1100<br>> CC:
 m3devel@elegosoft.com<br>> Subject: Re: [M3devel] recent problems?<br>><br>> This is worrying as it seems some level of instability has been<br>> introduced by recent changes. mentor used to be fine.<br>><br>> On 17 Mar 2009, at 00:16, Jay wrote:<br>><br>>><br>>> mklib seems ok now, having started over with a new checkout, new<br>>> build.<br>>> Strange considering what I had already tried, this problem had been<br>>> plaguing me over a week.<br>>><br>>><br>>> stubgen doesn't hang with 1.5, will try 1.7 again/later.<br>>><br>>><br>>> But formsedit still crashes during startup intermittently,<br>>> and Cygwin X apps hang at startup.<br>>> ugh.<br>>> I know, I probably caused whatever problem..<br>>><br>>><br>>> - Jay<br>>><br>>><br>>><br>>> ----------------------------------------<br>>>> From:
 jay.krell@cornell.edu<br>>>> To: hosking@cs.purdue.edu<br>>>> CC: m3devel@elegosoft.com<br>>>> Subject: RE: [M3devel] recent problems?<br>>>> Date: Mon, 16 Mar 2009 08:57:40 +0000<br>>>><br>>>><br>>>> Thanks.<br>>>><br>>>><br>>>> Here is another one.<br>>>> I found this testing moving PPC_DARWIN to "my headers".<br>>>> formsedit crashes during startup roughly more than<br>>>> half the times I start up, but not every time.<br>>>> The stack is always the same.<br>>>> I'll test it without my change.<br>>>> I think it'll happen either way, but I'll see.<br>>>> Yes, it recurs without my change, though I double<br>>>> check that my change is really undone.<br>>>> I'll have to dig into this.<br>>>><br>>>><br>>>> How does one get the code from CVS corresponding to a
 date?<br>>>> cvs upd -D ?<br>>>> I'll try that or something, see if I can find when things<br>worked.<br>>>><br>>>><br>>>> I should also be able to try the mklib crashing scenario<br>>>> on other platforms. It normally doesn't run on other<br>platforms.<br>>>><br>>>><br>>>> stubgen..if I'm ambitious, I can run in a loop on another<br>platform.<br>>>> But I think just moving Cygwin off of pthreads will<br>"fix" it<br>>>> and provide a cleaner base (not due to pthreads, but the Cygwin<br>>>> stuff).<br>>>><br>>>><br>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.<br>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004<br>>>> [Switching to process 19583 thread 0x2643]<br>>>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows<br>>>> (M3_Ao3CED_v=0x1f1eef4) at
 ../src/lego/POSIX/Sc<br>>>> rollerVBTClass.m3:325<br>>>> 325 VBT.PaintTint(v, r, v.shadow.bg);<br>>>> (gdb) bt<br>>>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows<br>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI<br>>>> X/ScrollerVBTClass.m3:325<br>>>> #1 0x0031766c in ScrollerVBTClass__PaintView<br>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV<br>>>> BTClass.m3:292<br>>>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4,<br>>>> M3_A0Kbc5_rgn=0xf0284778) at ../<br>>>> src/lego/POSIX/ScrollerVBTClass.m3:693<br>>>> #3 0x0031a590 in ScrollerVBTClass__Redisplay<br>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV<br>>>> BTClass.m3:706<br>>>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at<br>../<br>>>> src/vbt/VBTClass.m3:367<br>>>>
 #5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652<br>>>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/<br>>>> VBTRep.m3:601<br>>>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../<br>>>> src/vbt/VBTRep.m3:606<br>>>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940)<br>>>> at ../src/thread/PTHREAD/ThreadP<br>>>> Thread.m3:531<br>>>> #9 0x0132fb58 in ThreadPThread__ThreadBase<br>>>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr<br>>>> eadPThread.m3:508<br>>>> #10 0x9002b908 in _pthread_body ()<br>>>> (gdb)<br>>>><br>>>><br>>>><br>>>> - Jay<br>>>><br>>>><br>>>><br>>>> ----------------------------------------<br>>>>> From: hosking@cs.purdue.edu<br>>>>> To:
 jay.krell@cornell.edu<br>>>>> Date: Mon, 16 Mar 2009 08:10:05 +1100<br>>>>> CC: m3devel@elegosoft.com<br>>>>> Subject: Re: [M3devel] recent problems?<br>>>>><br>>>>> You might have structure sizes wrong and your stack will get<br>shifted<br>>>>> around as the command line changes length. You get some data<br>in a<br>>>>> structure wrong and then hit the wrong stack org and you might<br>see<br>>>>> problems like this.<br>>>>><br>>>>> I am not running things totally off of the head, so if the<br>problem<br>>>>> was<br>>>>> introduced recently it might only now be seen.<br>>>>><br>>>>> On 16 Mar 2009, at 06:15, Jay wrote:<br>>>>><br>>>>>><br>>>>>> I'm seeing some problems lately. Maybe it is just me.<br>>>>>> Some of them I've had over
 a week (ie: before my<br>(most) recent<br>>>>>> changes),<br>>>>>> some of them even if recently appeared I verified without<br>my (most)<br>>>>>> recent changes.<br>>>>>><br>>>>>> On Cygwin 1.5, mklib always crashes. I haven't been<br>able to debug<br>>>>>> it.<br>>>>>> This has been over a week.<br>>>>>> I've had to stop using Cygwin for Modula-3 development<br>on this<br>>>>>> machine.<br>>>>>> I have a good repro but hadn't had luck yet debugging<br>it.<br>>>>>> Basically if I shorten the mklib command line (in the<br>response<br>>>>>> file) substantially, no crash.<br>>>>>> There is a cut off somewhere.<br>>>>>><br>>>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but<br>not always<br>>>>>>
 hangs.<br>>>>>> It hangs nowhere else.<br>>>>>> This I verified occured without my recent changes.<br>>>>>> I only just in the past few days tried Cygwin 1.7.<br>>>>>> mklib works fine here.<br>>>>>> Of course since this is somewhat intermittent, maybe it<br>isn't a new<br>>>>>> problem.<br>>>>>><br>>>>>> I've only tried Cygwin 1.5 and 1.7 on one machine<br>each, separate<br>>>>>> machines,<br>>>>>> though they do coexist ok on one machine.<br>>>>>> 1.7 seemed much faster (on an unimpressive machine),<br>though 1.7<br>>>>>> binares<br>>>>>> apparently don't run on 1.5 -- at least not if they<br>use assert().<br>>>>>> 1.7 is a recent past or future release, a long time in the<br>works,<br>>>>>> drops Win9x support, lots of good
 sounding changes.<br>>>>>><br>>>>>> I should run m3tests more, maybe they will reveal the<br>crash or the<br>>>>>> hang as well.<br>>>>>><br>>>>>> On LINUXLIBC6 on one machine stubgen was crashing at least<br>in one<br>>>>>> directory.<br>>>>>> But I think this stopped happening.<br>>>>>><br>>>>>> Cygwin being broken pushes me to other platforms more,<br>probably a<br>>>>>> good thing.<br>>>>>> I'm loathe to debug the hang. When it occurs I<br>can't see any stacks<br>>>>>> in gdb. I can see in strace..<br>>>>>> I think we are waiting for all the threads to suspend<br>themselves.<br>>>>>> I'll probably try moving back to Win32 threads and see<br>if it clears<br>>>>>> up.<br>>>>>> I know that's not
 great.<br>>>>>> There isn't a clear implied question and I know I<br>should/need to<br>>>>>> look into these,<br>>>>>> but I also thought I shouldn't keep this to myself. I<br>also<br>>>>>> understand the philosophy<br>>>>>> of stopping changes when there are problems, to stop<br>further<br>>>>>> damage, but, of course,<br>>>>>> I'm very confident in my changes (always..), have been<br>testing them<br>>>>>> on other platforms,<br>>>>>> and looking them over extra extra since I know of these<br>other<br>>>>>> problems.<br>>>>>><br>>>>>> I'm not sure any problem on Cygwin is worrisome<br>really.<br>>>>>> I think the underlying code is kind of gnarly and I<br>don't think<br>>>>>> anyone uses this platform, though people asked for
 it.<br>>>>>> But I did have a crash on LINUXLIBC6.<br>>>>>><br>>>>>> - Jay<br>>>>><br>></pre></blockquote></td></tr></table><br>