Closed Bug 1003441 Opened 10 years ago Closed 9 years ago

crash in nsViewManager::ReparentChildWidgets(nsView*, nsIWidget*)

Categories

(Core :: Layout, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla41
Tracking Status
firefox39 --- fixed
firefox40 --- fixed
firefox41 --- verified
firefox-esr38 38+ fixed
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: martijn.martijn, Assigned: MatsPalmgren_bugz)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(4 files)

Attached file crash1.xul
This is a xul file and the crash testcase might be only reproduced locally.

This bug was filed from the Socorro interface and is 
report bp-8572b6e6-4a5e-4919-8b79-5d3752140429.
=============================================================
0 	XUL 	nsViewManager::ReparentChildWidgets(nsView*, nsIWidget*) 	view/src/nsViewManager.cpp
1 	XUL 	nsViewManager::InsertChild(nsView*, nsView*, nsView*, bool) 	view/src/nsViewManager.cpp
2 	XUL 	nsSubDocumentFrame::Init(nsIContent*, nsIFrame*, nsIFrame*) 	layout/generic/nsSubDocumentFrame.cpp
3 	XUL 	nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsIFrame*, nsFrameItems&) 	layout/base/nsCSSFrameConstructor.cpp
4 	XUL 	nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsIFrame*, nsFrameItems&) 	layout/base/nsCSSFrameConstructor.cpp
5 	XUL 	nsCSSFrameConstructor::ContentRangeInserted(nsIContent*, nsIContent*, nsIContent*, nsILayoutHistoryState*, bool) 	layout/base/nsCSSFrameConstructor.cpp
6 	XUL 	nsCSSFrameConstructor::RecreateFramesForContent(nsIContent*, bool) 	layout/base/nsCSSFrameConstructor.cpp
7 	XUL 	mozilla::RestyleManager::ProcessRestyledFrames(nsStyleChangeList&) 	layout/base/RestyleManager.cpp
8 	XUL 	mozilla::RestyleManager::RestyleElement(mozilla::dom::Element*, nsIFrame*, nsChangeHint, mozilla::RestyleTracker&, bool) 	layout/base/RestyleManager.cpp
9 	XUL 	mozilla::RestyleTracker::DoProcessRestyles() 	layout/base/RestyleTracker.cpp
10 	XUL 	mozilla::RestyleManager::ProcessPendingRestyles() 	layout/base/RestyleTracker.h
Doesn't seem to crash for me anymore. Martijn can you reproduce anymore?
Flags: needinfo?(martijn.martijn)
I'm still crashing with latest trunk build on MacOSX10.9.5: https://crash-stats.mozilla.com/report/index/5a960a05-9e1b-451d-80c0-c11382150331
Flags: needinfo?(martijn.martijn)
Do you have a file named "aaa" in the same folder as the test file?
Flags: needinfo?(martijn.martijn)
Attached file stack linux64
I was able to reproduce this in a Linux64 debug build and got this
content process stack.  It looks like the same issue.
It looks like we have a deleted nsView still in the view tree and
then crash when we try to insert a new view into its parent.
I'm guessing the "aaa" file is not required since I didn't have one when I crashed.
Flags: needinfo?(martijn.martijn)
(In reply to Mats Palmgren (:mats) from comment #6)
> I'm guessing the "aaa" file is not required since I didn't have one when I
> crashed.

No, you shouldn't need the "aaa" file, I crash without it too.
Attached patch fix+testSplinter Review
I'm pretty sure this is what was originally intended here.
Having a frame that isn't a nsSubDocumentFrame should be handled
the same as having no frame at all.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d65ad78a0c24
Assignee: nobody → mats
Attachment #8610743 - Flags: review?(roc)
OS: Mac OS X → All
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/dd045b29da2b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment on attachment 8610743 [details] [diff] [review]
fix+test

Approval Request Comment
[Feature/regressing bug #]: none
[User impact if declined]: crash
[Describe test coverage new/current, TreeHerder]: have automated crashtest
[Risks and why]: low-risk; simple one-line patch
[String/UUID change made/needed]: none
Attachment #8610743 - Flags: approval-mozilla-beta?
Attachment #8610743 - Flags: approval-mozilla-aurora?
Verified fixed on the latest trunk build on MacOSX 10.9.5.
Status: RESOLVED → VERIFIED
Comment on attachment 8610743 [details] [diff] [review]
fix+test

Verified, safe patch, taking it.
Attachment #8610743 - Flags: approval-mozilla-beta?
Attachment #8610743 - Flags: approval-mozilla-beta+
Attachment #8610743 - Flags: approval-mozilla-aurora?
Attachment #8610743 - Flags: approval-mozilla-aurora+
Is this something we should consider for the longer-lived esr38/b2g37 branches?
Flags: needinfo?(mats)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #17)
> Is this something we should consider for the longer-lived esr38/b2g37
> branches?

Yeah, I don't see any reason not to.  It's a low-risk patch.
Flags: needinfo?(mats)
Comment on attachment 8610743 [details] [diff] [review]
fix+test

See comment 13 and other discussion in the bug.
Attachment #8610743 - Flags: approval-mozilla-esr38?
Attachment #8610743 - Flags: approval-mozilla-b2g37?
Attachment #8610743 - Flags: approval-mozilla-b2g34?
Attachment #8610743 - Flags: approval-mozilla-b2g37?
Attachment #8610743 - Flags: approval-mozilla-b2g37+
Attachment #8610743 - Flags: approval-mozilla-b2g34?
Attachment #8610743 - Flags: approval-mozilla-b2g34+
[Tracking Requested - why for this release]:

This fix has been requested for uplift to ESR38+ and therefore nominating this bug for tracking for ESR38+
Comment on attachment 8610743 [details] [diff] [review]
fix+test

Approving uplift to ESR 39 (38.1.0) as the fix is simple and has landed in beta and aurora as well.
Attachment #8610743 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
You need to log in before you can comment on or make changes to this bug.