[M3devel] recent problems?

Tue Mar 17 01:14:35 CET 2009

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/20090316/9cb6bab1/attachment-0002.html>