crash [@nsIFrame::GetStyleData]

RESOLVED DUPLICATE of bug 137216

Status

()

--
critical
RESOLVED DUPLICATE of bug 137216
14 years ago
7 years ago

People

(Reporter: csthomas, Unassigned)

Tracking

({crash, testcase})

Trunk
x86
Windows XP
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(2 attachments)

To reproduce:
1. Visit URL http://ctho.ath.cx/tmp/mozcrash/test.xul
2. Click the "start" button, then "run"
3. The browser either crashes immediately, or asserts a few times and becomes
unusable, and may subsequently crash (mrbkap seems to be experiencing this)

When I crash, nsHTMLReflowState passed "null" for blockFrame to
CalculateHypotheticalBox.  aBlockFrame is null, but ->GetStyleVisibility doesn't
crash directly until GetStyleData, which is trying to assert at
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsIFrame.h#611 but "this"
is null, so accessing mStyleContext causes the crash.

Filing unconfirmed as my testcase is far from minimized.  Stack coming in a minute.
Some tracing by Callek found that
http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#827
derefences aBlockFrame, even though
http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#836
implies null is an expected value.  The dereference can't be moved into the
if(aBlockFrame) though, because it's used outside of the if later here (actually
its only use):
http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#888
Severity: normal → critical
Keywords: crash
Created attachment 168819 [details]
Testcase

Minimal testcase based on that site.
This testcase doesn't crash for me in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030
But it crashes for me in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208
Keywords: testcase

Comment 4

14 years ago
aloha, a abs. pos. xul box that changes display type, boris likes this stuff ;-)
(In reply to comment #2)
> even though
> http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#836
> implies null is an expected value.

More likely, it implies that whoever wrote the code believed that all pointers
should be null-checked even when they should never be null.
Isn't this just a dup of bug 137216?
Depends on: 137216

*** This bug has been marked as a duplicate of 137216 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
(Assignee)

Updated

7 years ago
Crash Signature: [@nsIFrame::GetStyleData]
You need to log in before you can comment on or make changes to this bug.