[M3devel] recent problems?

[Jay]

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