Closed Bug 264620 Opened 20 years ago Closed 20 years ago

crash at nsTableOuterFrame::OuterReflowChild line 1317

Categories

(Core :: Layout: Tables, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: bernd_mozilla, Assigned: bernd_mozilla)

References

()

Details

(Keywords: crash, fixed-aviary1.0, fixed1.7.5)

Attachments

(2 files)

steps to reproduce:
1. load URL
2. hover over the images at the top of the page
3. TB1335249X, TB133187Z
Attached file stacktrace
we crash at

  if (aNeedToReflowCaption && !*aNeedToReflowCaption &&
      mInnerTableFrame == aChildFrame) {
    nsHTMLReflowCommand* command = childRS.path->mReflowCommand;
    if (command) {
      nsReflowType type;
      command->GetType(type);
      *aNeedToReflowCaption = eReflowType_StyleChanged == type;
    }
  }
  childRS.path is 0x00000
Attached patch patchSplinter Review
Only during the incr reflow the path should be dereferenced.

see
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#177
Assignee: nobody → bernd_mozilla
Status: NEW → ASSIGNED
Comment on attachment 162274 [details] [diff] [review]
patch

asking for r/sr and all approvals as this should also go into the branches. The
patch is low risk and does not regress the use case that this code covers (bug
222846)
Attachment #162274 - Flags: superreview?(bzbarsky)
Attachment #162274 - Flags: review?(bzbarsky)
Attachment #162274 - Flags: approval1.7.x?
Attachment #162274 - Flags: approval-aviary?
Comment on attachment 162274 [details] [diff] [review]
patch

r+sr=bzbarsky
Attachment #162274 - Flags: superreview?(bzbarsky)
Attachment #162274 - Flags: superreview+
Attachment #162274 - Flags: review?(bzbarsky)
Attachment #162274 - Flags: review+
fixed on trunk
bernd, please include a quick explanation of what the patch does, what kind of
testing it's had and what kinds of risks are associated with taking the patch.
doing that will help to expidite approval requests. thanks.
Before the patch I assumed that we can always retrieve the reflow command from
the reflow path. This is wrong. The only situation where the path is non zero is
during an incr. reflow for the child frame see code snippet below.

177  if (reason == eReflowReason_Incremental) {
178     // If the child frame isn't along the reflow path, then convert
179     // the incremental reflow to a dirty reflow.
180     path = aParentReflowState.path->GetSubtreeFor(aFrame);
181     if (! path)
182       reason = eReflowReason_Dirty;
183   }
184   else
185     path = nsnull;

I tested the patch with files from the regression tests. 

I consider the risk low, as this is only a fixup when we need to reflow the
caption frame in addition to the table frame. The worst thing that could happen
is that we don't reflow the caption as previously. But I tested it specially
with the testcases from the bug where this code was introduced.
Comment on attachment 162274 [details] [diff] [review]
patch

a=asa for aviary and 1.7 checkin.
Attachment #162274 - Flags: approval1.7.x?
Attachment #162274 - Flags: approval1.7.x+
Attachment #162274 - Flags: approval-aviary?
Attachment #162274 - Flags: approval-aviary+
fix checked in into the branches
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: