If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash [@ nsHTMLReflowState::GetHypotheticalBoxContainer]

RESOLVED WORKSFORME

Status

()

Core
Layout
P2
critical
RESOLVED WORKSFORME
8 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: roc)

Tracking

({crash, regression, testcase})

Trunk
crash, regression, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Created attachment 414954 [details]
testcase

See testcase, which crashes current trunk build after 200ms.
It doesn't crash in Firefox3.5.

http://crash-stats.mozilla.com/report/index/b7ad0756-07c1-408b-a6c4-b72c42091129
0	xul.dll	nsHTMLReflowState::GetHypotheticalBoxContainer
1	xul.dll	nsHTMLReflowState::InitAbsoluteConstraints
2	xul.dll	nsHTMLReflowState::InitConstraints
3	xul.dll	nsHTMLReflowState::Init
4	xul.dll	nsAbsoluteContainingBlock::ReflowAbsoluteFrame
5	xul.dll	nsAbsoluteContainingBlock::Reflow
6	xul.dll	ViewportFrame::Reflow
7	xul.dll	PresShell::DoReflow
8	xul.dll	PresShell::ProcessReflowCommands
9	xul.dll	PresShell::FlushPendingNotifications
10	nspr4.dll	PR_Lock
11	xul.dll	nsThread::ProcessNextEvent
12	xul.dll	nsBaseAppShell::Run
13	nspr4.dll	PR_GetEnv
14	firefox.exe	wmain
15	firefox.exe	__tmainCRTStartup
16	kernel32.dll	BaseProcessStart
###!!! ASSERTION: Placeholder relationship should have been torn down; see comments in nsPlaceholderFrame.h.  Unregistering ourselves, but this might cause our out-of-flow to be unable to destroy itself properly.  Not that it could anyway, with us dead.: 'Error', file /home/dbaron/builds/mozilla-central/mozilla/layout/generic/nsPlaceholderFrame.cpp, line 137
###!!! ASSERTION: no placeholder frame: 'nsnull != placeholderFrame', file /home/dbaron/builds/mozilla-central/mozilla/layout/generic/nsHTMLReflowState.cpp, line 1165
Regression range:  2009-10-18-03 -- 2009-10-19-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a176eb500f88&tochange=d3298de30066
Backing out bug 504524 (changeset d3298de30066) locally fixes it.
Blocks: 504524
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
OS: Windows XP → All
Hardware: x86 → All
Created attachment 415061 [details] [diff] [review]
dirty lines

More specifically, adding back this block fixes the crash, fwiw.
We really don't want to add back those lines :-).

I assume this is not a problem on 1.9.2 since 504524 hasn't landed there.
blocking2.0: --- → ?
blocking2.0: ? → beta1
Priority: -- → P2
this is WFM/not crashing anymore using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.3a6pre) Gecko/20100618 Minefield/3.7a6pre (http://hg.mozilla.org/mozilla-central/rev/979b65e6b73e). seems to have been fixed/mitigated.
Bumping this to beta2 per beta re-triage with dbaron.  If this should indeed block beta1, please re-nom.
blocking2.0: beta1+ → beta2+
Assignee: nobody → roc
Moving to betaN - requires beta coverage, no specific beta milestone targetted at this time.
blocking2.0: beta2+ → betaN+
Does not crash for me. No assertions either. Can anyone reproduce this? Martijn?
(Reporter)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsHTMLReflowState::GetHypotheticalBoxContainer]
You need to log in before you can comment on or make changes to this bug.