145171 - Layout crash on loading http://gdargaud.net/Photo/index.html#Sygma [@IsPercentageAwareChild]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P2)

Description

[Yanko Kaneti]

from galeon bug http://bugzilla.gnome.org/show_bug.cgi?id=82018

Go to http://gdargaud.net/Photo/index.html#Sygma
Mozilla 1.0rc2  (20020513) crashes with:


#0  0x40e3fabf in IsPercentageAwareChild ()
   from /usr/lib/mozilla/components/libgklayout.so
#1  0x40e42ccf in nsBlockFrame::ReflowInlineFrame ()
   from /usr/lib/mozilla/components/libgklayout.so
#2  0x40e42bff in nsBlockFrame::DoReflowInlineFrames ()
   from /usr/lib/mozilla/components/libgklayout.so
#3  0x40e42997 in nsBlockFrame::DoReflowInlineFramesAuto ()
   from /usr/lib/mozilla/components/libgklayout.so
#4  0x40e4283c in nsBlockFrame::ReflowInlineFrames ()
   from /usr/lib/mozilla/components/libgklayout.so
#5  0x40e413c8 in nsBlockFrame::ReflowLine ()
   from /usr/lib/mozilla/components/libgklayout.so
#6  0x40e40b96 in nsBlockFrame::ReflowDirtyLines ()
   from /usr/lib/mozilla/components/libgklayout.so
#7  0x40e3f640 in nsBlockFrame::Reflow ()
   from /usr/lib/mozilla/components/libgklayout.so
#8  0x40e4c41b in nsContainerFrame::ReflowChild ()
   from /usr/lib/mozilla/components/libgklayout.so
#9  0x40eaa351 in nsFieldSetFrame::Reflow ()
   from /usr/lib/mozilla/components/libgklayout.so
#10 0x40e46a1a in nsBlockReflowContext::DoReflowBlock ()
   from /usr/lib/mozilla/components/libgklayout.so
#11 0x40e46576 in nsBlockReflowContext::ReflowBlock ()
   from /usr/lib/mozilla/components/libgklayout.so
#12 0x40e421a1 in nsBlockFrame::ReflowBlockFrame ()
   from /usr/lib/mozilla/components/libgklayout.so
#13 0x40e4101b in nsBlockFrame::ReflowLine ()
   from /usr/lib/mozilla/components/libgklayout.so
#14 0x40e40b96 in nsBlockFrame::ReflowDirtyLines ()
   from /usr/lib/mozilla/components/libgklayout.so
#15 0x40e3f640 in nsBlockFrame::Reflow ()
   from /usr/lib/mozilla/components/libgklayout.so
#16 0x40e4c41b in nsContainerFrame::ReflowChild ()
.......

Comment 1

[Laura Krietemeyer]

Changing QA Contact

Comment 2

[Andrew Schultz]

confirmed with Linux CVS from 20020517

debug build complains as follows:

###!!! ASSERTION: bad geometric parent: 'mFrames.ContainsFrame(aChild)', file
nsContainerFrame.cpp, line 922
Break: at file nsContainerFrame.cpp, line 922
###!!! ASSERTION: failed to remove frame: 'result', file nsContainerFrame.cpp,
line 960
Break: at file nsContainerFrame.cpp, line 960
###!!! ASSERTION: No style context found!: 'mStyleContext', file
../../../../dist/include/layout/nsIFrame.h, line 564
Break: at file ../../../../dist/include/layout/nsIFrame.h, line 564

severity critical, crash keyword.

Comment 3

[Andrew Schultz]

Attachment: reduced testcase

Comment 4

[Andrew Schultz]

The crash started occurring due to the innocuous checkin for bug 139989.

Note that the image extends out of the fieldset.  That started occurring between
2002012911 and 2002013108, due to bug 120958.  Unfortunately, backing that patch
out of current CVS doesn't fix the crash.

Comment 5

[Chris Waterson]

I'm unable to reproduce this with a current trunk build. Is this still a problem?

Comment 6

[Chris Waterson]

Okay, I take that back. Just reproduced. Looking...

Comment 7

[Chris Waterson]

Something funky going on here around the time we get that first assertion. The
child (Inline(a)(3)@0x87242f4) thinks its parent is the fieldset frame, not the
fieldset's content frame:

FieldSet(fieldset)(1)@0x8723838 [parent=0x871e858] next=0x8724414
{38,0,1543,4721} [state=00800005] [content=0x871fed0] [sc=0x8723708]<
  Area(fieldset)(1)@0x872388c [parent=0x8723838] {0,0,1159,4275}
[state=0090000d] sc=0x8723908(i=6,b=0)<
    line 0x87243e8: count=2 state=inline,clean,prevmarginclean,not
impacted,wrapped,nobr[0x2020] mew=1159 {0,0,874,266} ca={0,0,6836,4275} <
      Placeholder(img)(1)@0x8724138 [parent=0x8723838] {0,209,0,0}
[state=00000004] outOfFlowFrame=Frame(img)(1)@0x8723ff4
      Text(2)@0x872419c [parent=0x8723838][0,9,F]  next=0x873b200
next-in-flow=0x873b200 {0,0,874,266} [state=20000024] sc=0x8724168<
        "over the "
      >
    > floaters <
      placeholder@0x8724138 Frame(img)(1) cl region={1136,0,5700,4275}
combinedArea={0,0,5700,4275}
    >
    line 0x873b248: count=1
state=inline,clean,prevmarginclean,impacted,wrapped,nobr[0x1028] {0,266,665,266} <
      Text(2)@0x873b200 [parent=0x872388c][9,7,F]  next=0x873b274
prev-in-flow=0x872419c next-in-flow=0x873b274 {0,266,665,266} [state=20000024]
sc=0x8724168<
        "years, "
      >
    >
    line 0x873b2bc: count=1
state=inline,clean,prevmarginclean,impacted,wrapped,nobr[0x1028] {0,532,684,266} <
      Text(2)@0x873b274 [parent=0x872388c][16,7,F]  next=0x873b2e8
prev-in-flow=0x873b200 next-in-flow=0x873b2e8 {0,532,684,266} [state=20000024]
sc=0x8724168<
        "mainly "
      >
    >
    line 0x873b330: count=1
state=inline,clean,prevmarginclean,impacted,wrapped,nobr[0x1028] {0,798,912,266} <
      Text(2)@0x873b2e8 [parent=0x872388c][23,10,F]  next=0x873b35c
prev-in-flow=0x873b274 next-in-flow=0x873b35c {0,798,912,266} [state=20000024]
sc=0x8724168<
        "featuring "
      >
    >
    line 0x873b3a4: count=2 state=inline,dirty,prevmarginclean,not impacted,not
wrapped,nobr[0x2001] {0,1064,1159,266} <
      Text(2)@0x873b35c [parent=0x872388c][33,33,T]  next=0x87242f4
prev-in-flow=0x873b2e8 {0,1064,3496,266} [state=40000024] sc=0x8724168<
        "Antarctica, mountain climbing or "
      >
      Inline(a)(3)@0x87242f4 [parent=0x8723838] next=0x873b52c
next-in-flow=0x873b52c {0,1862,1444,266} [state=00000004] [content=0x87200d8]
[sc=0x8724264]<
        Text(0)@0x8724360 [parent=0x87242f4][0,14,T]  {0,0,1444,266}
[state=40000024] sc=0x872432c<
          "other pictures"
        >
      >
    >
    line 0x873b564: count=2 state=inline,dirty,prevmargindirty,impacted,not
wrapped,nobr[0x200b] {0,2128,893,266} <
      Inline(a)(3)@0x873b52c [parent=0x8723838] next=0x87243a4
prev-in-flow=0x87242f4 {0,2128,836,266} [state=00000004] [content=0x87200d8]
[sc=0x8724264]<>
      Text(4)@0x87243a4 [parent=0x8723838][0,12,T]  {836,2128,57,266}
[state=74000024] sc=0x8724168<
        ".\n          "
      >
    >
    Floater-list<
      Frame(img)(1)@0x8723ff4 [parent=0x8723838] {1136,0,5700,4275}
[state=00000124] [content=0x8720d08] [src=http://gdargaud.net/300/AdelieBlueSky.jpg]
    >
  >
>

Comment 8

[Chris Waterson]

Attachment: fix

The fieldset frame overrides the frame manipulation code to append, insert, and
replace frames into its child `content frame'. The problem is that it doesn't
fix the new frames' parent pointers before doing so. This patch does the fixup,
and adds an assertion in the block code to ensure that we can catch this sort
of problem earlier.

Comment 9

[Chris Waterson]

rods, could you r=? dbaron, you too? alex: do you know of any other fieldset
bugs like this? (I thought that I'd seen a few...)

Comment 10

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

Comment on attachment 84956 [details] [diff] [review]
fix

r=dbaron.  Presumably there aren't any issues with views, are there? 
(mContentFrame presumably doesn't have a view.	Should that be an
NS_ASSERTION?)

Comment 11

[Chris Waterson]

cc'ing kin for sr=?

Comment 12

[Chris Waterson]

Attachment: re-order {ib} logic to avoid assertion

Oops, my assertion trips over the {ib} code.

dbaron, although I don't _think_ that views would be an issue in this specific
case, it might be nice to consolidate this logic. For example, the {ib} code
does a bunch of junk like this.

Let me run with this patch for a few more days to see what other assertions I
hit.

Comment 13

[Alexandru Savulov]

nop, i don't know any (important) fieldset bugs right now although i recall
there was something sometime ago, hmmm. (sorry for the late response)

maybe attinasi's in-box has some (there must be some :-)

Comment 14

[R.K.Aa.]

*** Bug 175724 has been marked as a duplicate of this bug. ***

Comment 15

[Jacob Nordfalk]

My post (Bug 175724) has been marked as a duplicate of this one, so I post here
instead. I have made a very small HTML file that makes my browser crash:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
	<STYLE>
	<!--
		H2:first-letter { float: left; font-size: 0% }
	-->
	</STYLE>
</HEAD>
<BODY>
<H2>Crash</H2>
</BODY>
</HTML>


If font-size: 0% is changed to ex. 10% the browser doesent crach.
Unfortunately OpenOffice.org generates HTML with this 
		H2:first-letter { float: left; font-size: 0% }

I hope this helps.

Comment 16

[Jacob Nordfalk]

Attachment: The example that makes the browser crash

Comment 17

[Carine Held]

WFM on 21/23 Linux Trunk build.

With 6/11/02 Trunk build on Linux, I crash using the testcase Jacob added in #6.

Comment 18

[Andrew Schultz]

worksforme with URL and testcases from comment 3 and comment 16 using linux
trunk 20030106

Comment 19

[Boris Zbarsky [:bzbarsky]]

Marking so.