[M3devel] formsedit crash during startup sometimes?

[Tony Hosking]

I may have some time to look at this later next week.

On 20 Mar 2009, at 10:18, Jay wrote:

>
> I don't know yet.
> I just know that it happens before and after switching to "new small  
> unix/*.i3 files", so not that.
>
>
> I'm away for a few days with only an x86 laptop, I might get around  
> to testing something in a virtual machine, see if repros. Otherwise  
> it'll wait a bit.
>
>
> Soon I will probably resort to going back to 5.4.0 or something,  
> verifying no repro, then do "time bisection" or whatever you call it  
> ("binary search"?) -- jump ahead some chunk of time, ideally half  
> way between then and now, see if it repros, jump forward or backward  
> half again depending on if it repros, etc..
>
>
> Wouldn't it be super cool, though if I could just issue one command,  
> wait overnight or whatever, and voila, several of those builds done,  
> in both directions, just awaiting human test/observation? Yeah..
>
>
> I don't even know how yet to sync an entire CVS tree to a date yet,  
> maybe cvs upd -d?
> (Nice thing about 5.4.0 is I don't need CVS to identify it.)
>
>
> I also need to ensure that the non-repro case hits the line in  
> question and if so..well, what I'd really love to do, but not sure  
> how viable it is, is write code within the running system (before it  
> runs), to set a hardware breakpoint on the appropriate address, for  
> each appropriate address as the data types are created, and just  
> have dump core when it hits. I wasn't able to get it to even repro  
> in debugger for SOLgnu. I'll try PPC_DARWIN in a debugger, but even  
> if it repros I'm a bit pessimistic on tracking it down.
>
> Bisection while tedious and slow should definitely converge on the  
> answer.
>
>
> - Jay
>
>
> ________________________________
>> CC: m3devel at elegosoft.com
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Subject: Re: [M3devel] formsedit crash during startup sometimes?
>> Date: Thu, 19 Mar 2009 22:07:56 +1100
>>
>> This is a new bug. What changes introduced it?
>>
>> On 19 Mar 2009, at 21:22, Jay wrote:
>>
>> RTHooks__CheckLoadTracedRef is I'm sure innocent. It gets called  
>> before any pointer deref, I guess. The problem is the pointer is  
>> sometimes null, sometimes not. And why that is is what we need to  
>> figure out.
>>
>> - Jay
>>
>>
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Thu, 19 Mar 2009 07:47:47 +0000
>>> Subject: [M3devel] formsedit crash during startup sometimes?
>>>
>>>
>>> Formsedit on SOLgnu also crashes, sometimes, during startup.
>>> It doesn't seem to crash in a debugger, but you can load up the  
>>> core dump after a crash. It looks very similar as on PPC_DARWIN.
>>>
>>>
>>> In both cases, it is dereferencing the value 4, just after calling  
>>> RTHooks__CheckLoadTracedRef? Relevant? Coincidence?
>>>
>>>
>>> -bash-3.00$ uname -a
>>> SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100
>>> -bash-3.00$ rm core
>>> -bash-3.00$ ./formsedit
>>> Segmentation Fault (core dumped)
>>> -bash-3.00$ dbx ./formsedit ./core
>>> ...
>>> t at 2 (l at 2) terminated by signal KILL (Killed)
>>> 0xfe3c03d0: ___nanosleep+0x0008: bcc,a,pt %icc,___nanosleep+0x18 !  
>>> 0xfe3c03e0
>>> (dbx) lwps
>>> l at 1 LWP suspended in lwp_yield()
>>>> l at 2 LWP suspended in ___nanosleep()
>>> l at 3 LWP suspended in __lwp_park()
>>> l at 4 LWP suspended in ___nanosleep()
>>> l at 11 LWP suspended in __lwp_park()
>>> l at 12 LWP suspended in __lwp_park()
>>> l at 13 LWP suspended in __lwp_park()
>>> o l at 27 signal SIGSEGV in ScrollerVBTClass__PaintViewWithShadows()
>>> l at 28 LWP suspended in __lwp_park()
>>> (dbx) lwp l at 27
>>> t at 27 (l at 27) stopped in ScrollerVBTClass__PaintViewWithShadows at  
>>> 0xff1b945c
>>> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld  
>>> [%g1], %g1
>>> (dbx) dis $pc - 0x10
>>> dbx: warning: unknown language, 'c' assumed
>>> 0xff1b941c: ScrollerVBTClass__PaintViewWithShadows+0x0300: inc -4,  
>>> %g1
>>> 0xff1b9420: ScrollerVBTClass__PaintViewWithShadows+0x0304: ld  
>>> [%g1], %g1
>>> 0xff1b9424: ScrollerVBTClass__PaintViewWithShadows+0x0308: sll  
>>> %g1, 22, %g1
>>> 0xff1b9428: ScrollerVBTClass__PaintViewWithShadows+0x030c: srl  
>>> %g1, 31, %g1
>>> 0xff1b942c: ScrollerVBTClass__PaintViewWithShadows+0x0310: btog 1,  
>>> %g1
>>> 0xff1b9430: ScrollerVBTClass__PaintViewWithShadows+0x0314: and  
>>> %g1, 255, %g1
>>> 0xff1b9434: ScrollerVBTClass__PaintViewWithShadows+0x0318: cmp  
>>> %g1, 0
>>> 0xff1b9438: ScrollerVBTClass__PaintViewWithShadows+0x031c: bne,pt  
>>> %icc,ScrollerVBTClass__Pain
>>> tViewWithShadows+0x334 ! 0xff1b9450
>>> 0xff1b943c: ScrollerVBTClass__PaintViewWithShadows+0x0320: nop
>>> 0xff1b9440: ScrollerVBTClass__PaintViewWithShadows+0x0324: ld [%fp  
>>> - 24], %g1
>>> (dbx) dis
>>> 0xff1b9444: ScrollerVBTClass__PaintViewWithShadows+0x0328: mov  
>>> %g1, %o0
>>> 0xff1b9448: ScrollerVBTClass__PaintViewWithShadows+0x032c: call  
>>> RTHooks__CheckLoadTracedRef
>>> [PLT] ! 0xff2a9518
>>> 0xff1b944c: ScrollerVBTClass__PaintViewWithShadows+0x0330: nop
>>> 0xff1b9450: ScrollerVBTClass__PaintViewWithShadows+0x0334: ld [%fp  
>>> + 68], %g3
>>> 0xff1b9454: ScrollerVBTClass__PaintViewWithShadows+0x0338: ld [%fp  
>>> - 24], %g1
>>> 0xff1b9458: ScrollerVBTClass__PaintViewWithShadows+0x033c: inc 4,  
>>> %g1
>>> 0xff1b945c: ScrollerVBTClass__PaintViewWithShadows+0x0340: ld  
>>> [%g1], %g1
>>> 0xff1b9460: ScrollerVBTClass__PaintViewWithShadows+0x0344: st %g1,  
>>> [%fp - 180]
>>> 0xff1b9464: ScrollerVBTClass__PaintViewWithShadows+0x0348: add  
>>> %fp, -40, %g1
>>> 0xff1b9468: ScrollerVBTClass__PaintViewWithShadows+0x034c: add  
>>> %fp, -180, %g2
>>> (dbx) print $g1
>>> $g1 = 4ULL
>>> (dbx)
>>>
>>> I believe it is on the last line of the function, the PaintTint  
>>> call (due to what PPC_DARWIN showed).
>>>
>>>
>>> PROCEDURE PaintViewWithShadows (v: T) =
>>> VAR
>>> dom : Rect.T;
>>> stripe: Rect.T;
>>> r : Rect.T;
>>> f : Rect.Partition;
>>> BEGIN
>>> dom := VBT.Domain(v);
>>> stripe := ComputeStripe(v, dom);
>>> (* Paint the scroll. We are careful not to draw the area of the
>>> trough that will be covered by the stripe. This helps reduce
>>> the flicker. *)
>>> r := Rect.Inset(dom, v.shadowPixels);
>>> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Lowered,
>>> r, dom);
>>> Rect.Factor(r, stripe, f, 0, 0);
>>> FOR i := FIRST(f) TO LAST(f) DO
>>> IF i # 2 AND NOT Rect.IsEmpty(f[i]) THEN
>>> VBT.PaintTint(v, f[i], v.troughColor);
>>> END;
>>> END;
>>> (* Paint the stripe. *)
>>> r := Rect.Inset(stripe, v.shadowPixels);
>>> ShadowPaint.Border(v, Region.Full, v.shadow, Shadow.Style.Raised,
>>> r, stripe);
>>> VBT.PaintTint(v, r, v.shadow.bg);
>>> END PaintViewWithShadows;
>>>
>>>
>>> I'm somewhat just showing people how to get started debugging it,  
>>> in case folks are as afraid of command line debuggers as I used to  
>>> be.
>>>
>>>
>>> - Jay
>>