97226 - Browser crashes in gklayout.dll while loading URL [@ nsCSSRendering::PaintBackground]

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[Grey Hodge (jX)]

While doing heavy and serious research on the origins of man, I decided to see
what TV Guide had to say. Delving into their cover archive, Mozilla burped up a
big ol' GPF.  Happens conssitently, for me on Win98SE, and for someone else in
teh #mozillazine channel. 4 talkbacks reported, one is going to be attached here
as well. Just for kicks, here's Windows' error info:

MOZILLA caused an invalid page fault in
module GKLAYOUT.DLL at 017f:6039f89f.
Registers:
EAX=00000000 CS=017f EIP=6039f89f EFLGS=00010246
EBX=00000000 SS=0187 ESP=0068f498 EBP=0068f560
ECX=0068f568 DS=0187 ESI=01e47308 FS=44b7
EDX=0068f53c ES=0187 EDI=00003d86 GS=0000
Bytes at CS:EIP:
8b 08 ff 51 54 8b 45 08 8d 55 10 52 6a 12 8b 08 
Stack dump:
00000000 0068f53c 00000000 01e47308 026c8e20 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000

Comment 1

[Grey Hodge (jX)]

Attachment: Details from talkback incedent

Comment 2

[gsa]

crash also on mac nightly build id 2001082708
mac os error code 2 LAYOUT_DLL
nsCSSRendering::PaintBackground(nsIPresContext*, nsIRenderingContext&,
nsIFrame*, const nsRect&, const nsRect&, const nsStyleBackground&, const
nsStyleBorder&, int, int)+009AC

Comment 3

[Samuel Sieb]

With a debug build (from CVS, just finished building) I get this on the console:

###!!! ASSERTION: not a percent value: 'mUnit == eStyleUnit_Percent', file
../../../../dist/include/nsStyleCoord.h, line 159
###!!! Break: at file ../../../../dist/include/nsStyleCoord.h, line 159
###!!! ASSERTION: not a percent value: 'mUnit == eStyleUnit_Percent', file
../../../../dist/include/nsStyleCoord.h, line 159
###!!! Break: at file ../../../../dist/include/nsStyleCoord.h, line 159
Document http://www.tvguide.com/magazine/covers loaded successfully
###!!! ASSERTION: A canvas with a background image had no child frame, which is
impossible according to CSS. Make sure there isn't a background image specified
on the |:viewport| pseudo-element in |html.css|.: 'firstRootElementFrame', file
nsCSSRendering.cpp, line 2416
###!!! Break: at file nsCSSRendering.cpp, line 2416

and then a segfault.

Comment 4

[Samuel Sieb]

Moving to layout.

Here's a stack trace from the debugger:
#0  0x42001d8c in nsCSSRendering::PaintBackground (aPresContext=0x8728e00,
    aRenderingContext=@0x8895450, aForFrame=0x8756944, aDirtyRect=@0xbffff100,
    aBorderArea=@0xbfffef10, aColor=@0x876fe84, aBorder=@0x876545c, aDX=0,
    aDY=0) at nsCSSRendering.cpp:2420
#1  0x41f3968b in nsHTMLContainerFrame::Paint (this=0x8756944,
    aPresContext=0x8728e00, aRenderingContext=@0x8895450,
    aDirtyRect=@0xbffff100, aWhichLayer=eFramePaintLayer_Underlay)
    at nsHTMLContainerFrame.cpp:83
#2  0x41f3b3d1 in CanvasFrame::Paint (this=0x8756944, aPresContext=0x8728e00,
    aRenderingContext=@0x8895450, aDirtyRect=@0xbffff100,
    aWhichLayer=eFramePaintLayer_Underlay) at nsHTMLFrame.cpp:397
#3  0x41f708fe in PresShell::Paint (this=0x84b8da0, aView=0x8765738,
    aRenderingContext=@0x8895450, aDirtyRect=@0xbffff100)
    at nsPresShell.cpp:5380
#4  0x42171a86 in nsView::Paint (this=0x8765738, rc=@0x8895450,
    rect=@0xbffff100, aPaintFlags=128, aResult=@0xbffff118) at nsView.cpp:273
#5  0x4217c46d in nsViewManager::RenderDisplayListElement (this=0x8656c98,
    element=0x87b4d40, aRC=@0x8895450) at nsViewManager.cpp:1439
#6  0x4217c1ad in nsViewManager::RenderViews (this=0x8656c98,
    aRootView=0x854c820, aRC=@0x8895450, aRect=@0xbffff230,
    aResult=@0xbffff22c) at nsViewManager.cpp:1363
#7  0x4217accb in nsViewManager::Refresh (this=0x8656c98, aView=0x854c820,
    aContext=0x8895450, rect=0xbffff2e0, aUpdateFlags=1)
    at nsViewManager.cpp:899
#8  0x4217d9f5 in nsViewManager::DispatchEvent (this=0x8656c98,
    aEvent=0xbffff450, aStatus=0xbffff330) at nsViewManager.cpp:1958
#9  0x42171324 in HandleEvent (aEvent=0xbffff450) at nsView.cpp:67
#10 0x41093745 in nsWidget::DispatchEvent (this=0x8724ea0, aEvent=0xbffff450,
    aStatus=@0xbffff3fc) at nsWidget.cpp:1387
#11 0x41093366 in nsWidget::DispatchWindowEvent (this=0x8724ea0,
    event=0xbffff450) at nsWidget.cpp:1278
#12 0x41098db7 in nsWindow::DoPaint (this=0x8724ea0, aX=0, aY=0, aWidth=1273,
    aHeight=866, aClipRegion=0x8766468) at nsWindow.cpp:778
#13 0x41099021 in nsWindow::Update (this=0x8724ea0) at nsWindow.cpp:824
#14 0x41098aec in nsWindow::UpdateIdle (data=0x0) at nsWindow.cpp:692
#15 0x4045d9ad in g_idle_dispatch () from /usr/lib/libglib-1.2.so.0
#16 0x4045c8f3 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#17 0x4045cf38 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#18 0x4045d0fc in g_main_run () from /usr/lib/libglib-1.2.so.0
#19 0x40372933 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#20 0x4107f5b9 in nsAppShell::Run (this=0x810b528) at nsAppShell.cpp:349
#21 0x408612dd in nsAppShellService::Run (this=0x811fe20)
    at nsAppShellService.cpp:427
#22 0x0805aadc in main1 (argc=1, argv=0xbffff8c4, nativeApp=0x0)
    at nsAppRunner.cpp:1387
#23 0x0805b77f in main (argc=1, argv=0xbffff8c4) at nsAppRunner.cpp:1709

Comment 5

[Doron Rosenberg (IBM)]

really moving

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is due to the changes for bug 46446.  firstRootElementFrame seems to be
null (judging by the registers in the talkback info).

Ian - you stuck in an assertion, but we seem to be hitting that case some of the
time.  What should happen here?

Comment 7

[Hixie (not reading bugmail)]

I would guess (and this is only a guess) that the code is being called when the
page hasn't finished loading. I don't have access to a debugging environment 
right now, but poking around in a debugger when that assertion is hit should
explain what is going on.

As a stopgap solution, until we work out what is actually happening, replacing
the code around the assertion with something akin to:

    } else { 
      nsCOMPtr<nsIAtom> frameType;
      aForFrame->GetFrameType(getter_AddRefs(frameType));
      if (frameType.get() == nsLayoutAtoms::canvasFrame) {
        // If the frame is the canvas, the image is placed relative to
        // the root element's (first) frame (see bug 46446)
        nsRect firstRootElementFrameArea;
        nsIFrame* firstRootElementFrame;
        aForFrame->FirstChild(aPresContext, nsnull, &firstRootElementFrame);
        if (firstRootElementFrame) { // temporary null check -- see bug 97226
          firstRootElementFrame->GetRect(firstRootElementFrameArea);
          if (firstRootElementFrameArea) { // also temporary -- see bug 97226
            // Take the border out of the frame's rect
            const nsStyleBorder* borderStyle;
            [...]
            // Get the anchor point
            ComputeBackgroundAnchorPoint(aColor, [...]);
          } else {
            ComputeBackgroundAnchorPoint(aColor, paddingArea, paddingArea, 
                                         tileWidth, tileHeight, anchor);
          }
        } else {
          ComputeBackgroundAnchorPoint(aColor, paddingArea, paddingArea, 
                                       tileWidth, tileHeight, anchor);
        }
      } else {
        // Otherwise, it is the normal case, and the background is
        // simply placed relative to the frame's padding area
        ComputeBackgroundAnchorPoint(aColor, paddingArea, paddingArea, 
                                     tileWidth, tileHeight, anchor);
      }
     }

...should stop the crash.

Reassigning to dbaron.

dbaron: If you are ok with it, could you make a patch for the proposed change 
above? We can check that (or something similar) in now, and then when I'm set
up to compile again I'll try to understand what the real problem is.


Grey Hodge: Does http://www.tvguide.com/magazine/covers reliably crash for you
with both JavaScript turned on and JavaScript turned off, or does it only crash
if it shows the popup window?

Comment 8

[Grey Hodge (jX)]

Good question. It crashes WHILE loading, as opposed to after it's loaded, but
yes, only with Javascript enabled. Turning it off allows the page to loud
without bombing out.

Comment 9

[Samuel Sieb]

I've reduced it down to this javascript file:
http://serve.m-ave.net/jscript/MerchandisingAvenue.js

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The URLs reported in talkback report comments are:
http://www.kissasylum.com/
http://tvguide.com/magazine/covers
http://tvguide.com/

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this still happening in current builds?  I can't reproduce it.

Comment 12

[Grey Hodge (jX)]

Seems to be WFM now here as well...

Comment 13

[Jay Patel [:jay]]

Talkback data shows this last crashed with MozillaTrunk build 2001083109. 
Should this be marked wfm if no one is able to reproduce and we don't know of
any recent checkin that could have fixed this?

Comment 14

[Grey Hodge (jX)]

Agreed. I can't reproduce it for anything, now. Opening up a slightly older
build I can, but not on current builds. Marking WFM. But if anyone has an idea
what fixed it, post it.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reopening this.  There have still been a few talkback reports in recent builds.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: proposed patch (diff -u)

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: proposed patch (diff -uw)

Comment 18

[Hixie (not reading bugmail)]

r=hixie

Comment 19

[Chris Waterson]

Any explanation as to why the frame is null at this point? sr=waterson

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I really don't know why it's null.  Could it be because the frame tree is
partially constructed (in which case we really need the null-check)?

Comment 21

[Asa Dotzler [:asa]]

Comment on attachment 48848 [details] [diff] [review]
proposed patch (diff -uw)

a=asa for checkin to 0.9.4

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to trunk 2001-09-10 12:37 PDT and 0.9.4 branch 2001-09-10 14:43 PDT.

Filed bug 99176 to figure out the real cause of the problem.  Marking FIXED.

Comment 23

[Chris Petersen]

Verified in the Sept 28th branch build. Mac OS X (2001-09-28-04) and Windows ME
(2001-09-28-05).