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

VERIFIED FIXED in mozilla0.9.9

Status

()

Core
Layout
P1
major
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Bob Kanefsky, Assigned: Marc Attinasi)

Tracking

({crash, testcase})

Trunk
mozilla0.9.9
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

16 years ago
Created attachment 67870 [details]
Test case that crashes Mozilla for me
(Reporter)

Updated

16 years ago
Keywords: crash
Summary: Crash when setting style.display of TR element (table row) → Unmapped memory when setting style.display of TR element (table row)

Comment 2

16 years ago
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.
OS: Mac System 9.x → All
Hardware: Macintosh → All
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.
Assignee: jst → attinasi
Component: DOM Style → Layout
QA Contact: ian → petersen
(Reporter)

Comment 4

16 years ago
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.
confirmed on WINNT using build 2002013103 build.
Marking nsbeta1+
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.9

Updated

16 years ago
Priority: -- → P1

Comment 6

16 years ago
Added testcase keyword
Keywords: testcase
(Assignee)

Comment 7

16 years ago
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.
Status: NEW → ASSIGNED
(Reporter)

Comment 8

16 years ago
Created attachment 68665 [details]
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.
This sounds similar to another bug for which somebody attached a patch.
Could this be bug 118465?
(Assignee)

Comment 11

16 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 12

16 years ago
David, thanks for the cross-reference tip!
(Reporter)

Comment 13

16 years ago
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 14

16 years ago
Works for me with recent build...
(Assignee)

Comment 15

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

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

(Reporter)

Comment 16

16 years ago
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.
(Assignee)

Comment 17

16 years ago
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.
(Assignee)

Comment 18

16 years ago
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!
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 19

16 years ago
Verified in the April 17 OS X build (2002-04-17-03) and Windows ME (2002-04-17-11).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.