[M3devel] recent problems?

[Jay]

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