[M3devel] recent problems?

Mon Mar 16 15:54:34 CET 2009

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