123490 - Unmapped memory when setting style.display of TR element (table row)

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Bob Kanefsky]

I have repeated crashed build #2002020405 (0.9.8) and 0.9.7 on MacOS 9.1 with
the attached file.

Comment 1

[Bob Kanefsky]

Attachment: Test case that crashes Mozilla for me

Comment 2

[Arthur]

Crashing on 0.9.8 (linux) when clicking several times on B in the testcase and
then on A. Memory usage skyrockets until mozilla crashes. Talkback not triggered.

Comment 3

[Johnny Stenback (:jst)]

IIRC there's other bugs about this same problem, here's the stack for the
endless loop we get stuck in:

nsBlockFrame::AddFrames(nsBlockFrame * const 0x02c52ed0, nsIPresContext *
0x00000000, nsIFrame * 0x02c52ed0, nsIFrame * 0x00000000) line 4788
nsBlockFrame::SetInitialChildList(nsBlockFrame * const 0x02c5319c,
nsIPresContext * 0x02bc06e8, nsIAtom * 0x00000000, nsIFrame * 0x02c52ed0) line 6113
ProcessPseudoFrame(nsIPresContext * 0x02bc06e8, nsPseudoFrameData & {...},
nsIFrame * & 0x02c5319c) line 1560 + 12 bytes
ProcessPseudoCellFrame(nsIPresContext * 0x02bc06e8, nsPseudoFrames & {...},
nsIFrame * & 0x02c5319c) line 1606 + 18 bytes
ProcessPseudoFrames(nsIPresContext * 0x02bc06e8, nsPseudoFrames & {...}, nsIAtom
* 0x00000000, nsIFrame * & 0x02c5319c) line 1677
ProcessPseudoFrames(nsIPresContext * 0x02c5319c, nsPseudoFrames & {...},
nsFrameItems & {...}) line 1705 + 18 bytes
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x02bc1fc0,
nsIPresContext * 0x02bc06e8, nsIContent * 0x02c4a288, nsIContent * 0x02c53c18,
int 46484480, nsILayoutHistoryState * 0x02c439e8, int 0) line 8769 + 19 bytes
nsCSSFrameConstructor::RecreateFramesForContent(nsCSSFrameConstructor * const
0x02c52ed0, nsIPresContext * 0x00000000, nsIContent * 0x02c53c18, int 1,
nsIStyleRule * 0x025fdf28, nsIStyleContext * 0x02c51dcc) line 11875 + 20 bytes
nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const
0x02bc1fc0, nsIPresContext * 0x02bc06e8, nsIContent * 0x02c53c18, int 0, nsIAtom
* 0x0103db18, int 1, int 6) line 10560 + 21 bytes
StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x02bc3008, nsIPresContext *
0x02bc06e8, nsIContent * 0x02c53c18, int 0, nsIAtom * 0x0103db18, int 1, int 6)
line 1495
PresShell::AttributeChanged(PresShell * const 0x02bc31b0, nsIDocument *
0x02bbbca0, nsIContent * 0x02c53c18, int 0, nsIAtom * 0x0103db18, int 1, int 6)
line 5123
nsDocument::AttributeChanged(nsDocument * const 0x02bbbca0, nsIContent *
0x02c53c18, int 0, nsIAtom * 0x0103db18, int 1, int 6) line 1993
nsHTMLDocument::AttributeChanged(nsHTMLDocument * const 0x02bbbca0, nsIContent *
0x02c53c18, int 0, nsIAtom * 0x0103db18, int 1, int 6) line 1465 + 19 bytes
nsDOMCSSAttributeDeclaration::ParsePropertyValue(nsDOMCSSAttributeDeclaration *
const 0x02c52ed0, const nsAString & {...}, const nsAString & {...}) line 282
CallSetProperty(nsDOMCSSDeclaration * 0x02bee728, const nsAString & {...}, const
nsAString & {...}) line 223 + 12 bytes
nsDOMCSSDeclaration::SetDisplay(nsDOMCSSDeclaration * const 0x02bee72c, const
nsAString & {...}) line 283 + 47 bytes

Over to layout.

Comment 4

[Bob Kanefsky]

Talkback *was* triggered on Mac (at least in next invocation).  I entered this
bug number in the comments field on one of the last I sent.

Comment 5

[Kevin McCluskey (gone)]

confirmed on WINNT using build 2002013103 build.
Marking nsbeta1+

Comment 6

[Chris Petersen]

Added testcase keyword

Comment 7

[Marc Attinasi]

Looks like we are spinning forever in nsBlockFrame::AddFrames because a frame's
nextSibling is being returned as itself.  Once I added a check for this, and
broke the infinite loop, we hit it elsewhere (FrameManager::CaptureFrameState)
trying to reload the document.

The frame tree is getting hosed, I need to figure out why.

Comment 8

[Bob Kanefsky]

Attachment: Similar test case with display:table-row

Did you notice that my original test case unintentionally messes up the layout?
 I didn't know about "display:table-row" and used "display:inherit".

However, it crashes either way.

Comment 9

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

This sounds similar to another bug for which somebody attached a patch.

Comment 10

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

Could this be bug 118465?

Comment 11

[Marc Attinasi]

The patch for bug 118465 fixes this bug.  I'm marking this a dup of bug 118465
and sr'ing that bug so we can get this checked in.



*** This bug has been marked as a duplicate of 118465 ***

Comment 12

[Marc Attinasi]

David, thanks for the cross-reference tip!

Comment 13

[Bob Kanefsky]

Bug #118465 is fixed, but Bug #123490 is not.

Mozilla 0.9.8 (build 2002020405)
  - hangs on Attachment #63752 [details] (Bug #118465)
  - hangs on Attachment #63754 [details] (Bug #118465)
  - crashes or hangs on Attachment #67870 [details] (Bug #123490) with enough clicking

Nightly build 2002021303
  - works on Attachment #63752 [details] (Bug #118465)
  - works on Attachment #63754 [details] (Bug #118465)
  - crashes on Attachment #67870 [details] (Bug #123490) with a few clicks -- TB2893529M

Comment 14

[Denis Antrushin]

Works for me with recent build...

Comment 15

[Marc Attinasi]

- crashes on Attachment #67870 [details] (Bug #123490) with a few clicks -- TB2893529M

This works fine for me, windows 2000 build from 02/13

Comment 16

[Bob Kanefsky]

I was unable to crash it a second time, but the talkback should speak for
itself.  Unfortunately, I didn't note the exact sequence of checkboxes I tried
this time.  I think it involved some B's, then some A's or maybe C's, and was
less than ten clicks but more than three.  On my second try, it never crashed,
although the memory usage went up 100k and the visible outline of the table kept
getting taller.

Comment 17

[Marc Attinasi]

I clicked on every box I could find, dozens of times in all sorts of orders. 
Petersen, can you try it out please?  I'll try to get the talkback data and see
if it was some other error or this one.

Comment 18

[Marc Attinasi]

The stack from your talkback looks very different.  Here is what I saw on the
talkback server for ID TB2893529M

0x61aa61a8
content.shlb + 0x17dd8 (0x0eab21f8)
layout.shlb + 0x22b2c (0x0e5a43cc)
content.shlb + 0xa2f0 (0x0eaa4710)
content.shlb + 0xa0834 (0x0eb3ac54)
content.shlb + 0x9b048 (0x0eb35468)
layout.shlb + 0x2567c (0x0e5a6f1c)
layout.shlb + 0x252d4 (0x0e5a6b74)
view.shlb + 0x10d48 (0x0e570c48)
view.shlb + 0x6bc8 (0x0e566ac8)
view.shlb + 0x10164 (0x0e570064)
view.shlb + 0x6274 (0x0e566174)
widget.shlb + 0x4250 (0x0ea12d10) 


Closing again.  If you get this crash again, please reopen or file a new bug.
Thanks!

Comment 19

[Chris Petersen]

Verified in the April 17 OS X build (2002-04-17-03) and Windows ME (2002-04-17-11).