[M3devel] recent problems?

[Jay]

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
>