Closed
Bug 660588
Opened 13 years ago
Closed 13 years ago
Crash [@ nsCSSFrameConstructor::FindFrameForContentSibling(nsIContent*, nsIContent*, unsigned char&, int)] with null sibling
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla10
People
(Reporter: bc, Assigned: ehsan.akhgari)
References
()
Details
(Keywords: crash)
Crash Data
1. http://www.5ok.com.ua/DetailProduct_141_102_59.html 2. Crash nightly but not beta. haven't checked aurora yet. // If the frame is out-of-flow, GetPrimaryFrame() will have returned the // out-of-flow frame; we want the placeholder. if (sibling->GetStateBits() & NS_FRAME_OUT_OF_FLOW) { nsIFrame* placeholderFrame = mPresShell->FrameManager()->GetPlaceholderFrameFor(sibling); NS_ASSERTION(placeholderFrame, "no placeholder for out-of-flow frame"); sibling = placeholderFrame; } // The frame we have now should never be a continuation NS_ASSERTION(!sibling->GetPrevContinuation(), "How did that happen?"); Crash during the assertion with a null sibling. Therefore placeholderFrame was null. Assertions leading up to the crash are: ###!!! ASSERTION: unexpected child list: 'Error', file c:/work/mozilla/builds/nightly/mozi lla/layout/generic/nsBlockFrame.cpp, line 4708 ###!!! ASSERTION: How did that happen?: 'aFrameItems.IsEmpty()', file c:/work/mozilla/buil ds/nightly/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 1269 ###!!! ASSERTION: Frames getting lost!: 'NS_SUCCEEDED(rv)', file c:/work/mozilla/builds/ni ghtly/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 1274 ###!!! ASSERTION: Dangling child list. Someone forgot to insert it?: '!FirstChild()', fil e c:/work/mozilla/builds/nightly/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 637 ###!!! ASSERTION: not in child list: 'found', file c:/work/mozilla/builds/nightly/mozilla/ layout/base/nsLayoutUtils.cpp, line 361 ###!!! ASSERTION: unexpected child list: 'Error', file c:/work/mozilla/builds/nightly/mozi lla/layout/generic/nsBlockFrame.cpp, line 5029 ###!!! ASSERTION: asked to construct a frame for a node that already has a frame: '!child- >GetPrimaryFrame() || child->GetPrimaryFrame()->GetContent() != child', file c:/work/mozil la/builds/nightly/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6857 ###!!! ASSERTION: asked to create frame construction item for a node that already has a fr ame: 'Error', file c:/work/mozilla/builds/nightly/mozilla/layout/base/nsCSSFrameConstructo r.cpp, line 5014 ###!!! ASSERTION: no placeholder frame for out-of-flow frame: 'Not Reached', file c:/work/ mozilla/builds/nightly/mozilla/layout/generic/nsFrame.cpp, line 6615 frame: FrameOuter(iframe)(0) (06096428) style: 05E94340 {} ###!!! ASSERTION: Wrong parent style context: 'Error', file c:/work/mozilla/builds/nightly /mozilla/layout/base/nsFrameManager.cpp, line 640 Wrong parent style context: style: 05E944E0 {} should be using: style: 05E921F0 {} ###!!! ASSERTION: not in child list: 'found', file c:/work/mozilla/builds/nightly/mozilla/ layout/base/nsLayoutUtils.cpp, line 361 ###!!! ASSERTION: unexpected child list: 'Error', file c:/work/mozilla/builds/nightly/mozi lla/layout/generic/nsBlockFrame.cpp, line 5029 ###!!! ASSERTION: asked to construct a frame for a node that already has a frame: '!child- >GetPrimaryFrame() || child->GetPrimaryFrame()->GetContent() != child', file c:/work/mozil la/builds/nightly/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6857 ###!!! ASSERTION: no placeholder for out-of-flow frame: 'placeholderFrame', file c:/work/m ozilla/builds/nightly/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5901
Reporter | ||
Updated•13 years ago
|
Summary: Crash [@ nsCSSFrameConstructor::FindFrameForContentSibling()] with null sibling → Crash [@ nsCSSFrameConstructor::FindFrameForContentSibling(nsIContent*, nsIContent*, unsigned char&, int)] with null sibling
Updated•13 years ago
|
Crash Signature: [@ nsCSSFrameConstructor::FindFrameForContentSibling(nsIContent*, nsIContent*, unsigned char&, int)]
Reporter | ||
Comment 2•13 years ago
|
||
1. http://www.cs.bris.ac.uk/home/sp9857/ 2. Crash On Windows XP with a debug Nightly build I could not get visual studio to attach to the crash... :-( Using a nightly Nightly ( :-) ) I did get bp-94fbb117-6684-4d8f-8c7d-5e7b02110616 which implicates this bug. I also got bp-d27b903f-b136-4ff8-ae79-aa96b2110616 which is just xul.dll@crap without symbols. Automation on Windows 7 hit nsIFrame::IsBoxFrame() nsIFrame::IsBoxWrapped() nsFrame::MarkIntrinsicWidthsDirty() nsBlockFrame::MarkIntrinsicWidthsDirty() PresShell::FrameNeedsReflow(nsIFrame*, nsIPresShell::IntrinsicDirty, unsigned __int64)
Comment 3•13 years ago
|
||
I'm guessing this is due to ehsan's partial abs pos patches, but we need to track this anyway... Bob, please just nominate things like this for tracking when you file them?
tracking-firefox6:
--- → ?
tracking-firefox7:
--- → ?
Reporter | ||
Comment 4•13 years ago
|
||
I got pushback a while ago when I tried to use the tracking flags. It seemed to me that I wasn't supposed to be using them.
Reporter | ||
Comment 5•13 years ago
|
||
bug 606665 comment 6 seemed to imply that it is up to the component owners and not bug filers such as myself to using the tracking flags.
Comment 6•13 years ago
|
||
Gah. That's silly. OK, please feel free to just cc me on any crash regression you find in any component I'm remotely a peer or owner of... ;)
Assignee | ||
Comment 7•13 years ago
|
||
This is also fixed by one of the patches that I currently have in the queue.
Assignee: nobody → ehsan
Blocks: 10209
We'll track this for Firefox 7 as it would be a regression there. Can we confirm it does or does not happen on Firefox 6 (currently on Aurora)
Reporter | ||
Comment 9•13 years ago
|
||
I resubmitted http://www.5ok.com.ua/DetailProduct_141_102_59.html and http://www.cs.bris.ac.uk/home/sp9857/ to the crash automation and did not crash with either Aurora or Nightly on Windows XP, Windows 7 or Fedora. My Mac OS X crash automation machine is down as is my local ESXi host so I could not test locally with Windows or Linux. I tested the two urls locally with my Mac OS X 10.5 Macbook Pro and could not reproduce the crash either.
Comment 10•13 years ago
|
||
As I understand it, this was not a problem for Firefox 5 or for Firefox 6 (which was Aurora when this was reported against the trunk) so it is not a problem for Firefox 6 Beta. That means the only place it should be a problem is on trunk or current Aurora 7 (which doesn't have builds yet.) Is this "worksforme"?
Assignee | ||
Comment 11•13 years ago
|
||
No, it's a bug caused by the first two parts of bug 10209. I've backed them out for now, and will reland them with fixes to this crash.
status-firefox7:
--- → fixed
Assignee | ||
Comment 12•13 years ago
|
||
This is fixed with the new patches that I pushed today.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in
before you can comment on or make changes to this bug.
Description
•