Closed
Bug 1238928
Opened 8 years ago
Closed 8 years ago
crash in nsDisplayPerspective::BuildLayer
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla48
People
(Reporter: mstange, Assigned: mattwoodrow)
References
Details
(Keywords: crash, regression, testcase)
Crash Data
Attachments
(4 files)
12.40 KB,
text/plain
|
Details | |
30.87 KB,
text/plain
|
Details | |
536 bytes,
text/html
|
Details | |
1.27 KB,
patch
|
tnikkel
:
review+
lizzard
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-68c8b17f-1e83-4b61-a93c-727f12160112. ============================================================= I was on http://tympanus.net/Development/SeatPreview/ (click "Select your seats") and trying to drag the 180˚ button. Unfortunately I can't reproduce the crash that way. The stack trace shows that Firefox was trying to paint a drag image. Crash stats shows a few more crashes in nsDisplayPerspective::BuildLayer, most of them in DrawDrag.
Assignee | ||
Comment 1•8 years ago
|
||
I haven't been able to reproduce this yet, and it's not obvious what is wrong from the crash report.
Blocks: 1168263
Comment 2•8 years ago
|
||
I just hit this twice in a row (once with my main profile, once with a fresh profile). My STR were similar to comment 0 -- I was at http://thewebrocks.com/demos/mozilla-monument-name-finder/ and I simply clicked and dragged on & around the animation. The first time, I crashed instantly. The second time (fresh profile), I crashed after a minute or so of random clicking/dragging on the animation.
Comment 3•8 years ago
|
||
My crash reports: bp-340e87c5-9c52-4586-9251-95e0c2160323 bp-ba7e0d32-2c7b-4377-bf69-e9eae2160323
Comment 4•8 years ago
|
||
(Note: my first crash report has e10s disabled, my second one has it enabled.)
Comment 5•8 years ago
|
||
I was just able to trigger this in a debug build.
Inside of nsDisplayPerspective::BuildLayer, we have this code:
> nsDisplayTransform* transform =
> static_cast<nsDisplayTransform*>(mList.GetChildren()->GetTop());
>
> Point3D newOrigin =
> Point3D(NSAppUnitsToFloatPixels(transform->ToReferenceFrame().x, appUnitsPerPixel),
> NSAppUnitsToFloatPixels(transform->ToReferenceFrame().y, appUnitsPerPixel),
> 0.0f);
And the problem here is that |transform| is null. So transform->ToReferenceFrame() crashes on that null deref.
Comment 6•8 years ago
|
||
(A bit more information while I have this captured in GDB: - In that crashing nsDisplayPerspective call, this->mFrame is a nsBlockFrame, and I'm pretty sure it corresponds to <div class="rotatingmonument"> in the markup. - That block has this style applied to it: .rotatingmonument { position:absolute; top: 0; left: 80px; -webkit-perspective: 800px; perspective: 800px; transform-origin: 50% 20%; } http://thewebrocks.com/demos/mozilla-monument-name-finder/mozmonument.css * I'm attaching a GDB backtrace, and I'll attach a frame dump, too, for completeness.
Comment 7•8 years ago
|
||
Here's the frame tree. Our doomed nsDisplayPerspective's mFrame member-var is 0x7f55a95d1700, which you can see is a nsBlockFrame inside of an AbsoluteList here.
Comment 8•8 years ago
|
||
Also: in my crash, the HandlePositionedEvent call (level 21 of the backtrace) is being called on 0x7f55a95d8528 which is a nsTextFrame with contents "3" (marking the 3rd side of the monument). In another crash (just triggered it again & poked around again with gdb), HandlePositionedEvent was being called for the nsImageFrame for the firefox logo on top of the monument.
Comment 9•8 years ago
|
||
OK, I have a reasonably reduced testcase with pretty reliable STR. STR (also quoted in the testcase): 1. Click & drag from the upper-left of AAA to the bottom-right of "BBB" (so that they both end up highlighted). 2. Click and drag the now-highlighted "AAA" or "BBB". This isn't 100% reliable, but it usually makes the content process crash.
Comment 10•8 years ago
|
||
Matt, if you can reproduce with the attached testcase, I'm hoping you might be the right person to look into this.
Flags: needinfo?(matt.woodrow)
Keywords: testcase
Comment 11•8 years ago
|
||
Reproduces for me on mac. Display lists for drawing selections are unusual beasts.
Comment 12•8 years ago
|
||
Regression range, using mozregression: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ddd566eb39b7a39d0ff630343f179fedc8fcafd5&tochange=7e18014be68d9e13760b2814862745911caf49a5 That includes "Bug 1168263 - Add nsDisplayPerspective" (and this bug is a crash in that class). (I was about to mark this as blocking that bug, but I see mattwoodrow already did that in comment 1.)
Keywords: regression
Assignee | ||
Comment 13•8 years ago
|
||
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Attachment #8734213 -
Flags: review?(tnikkel)
Updated•8 years ago
|
Attachment #8734213 -
Flags: review?(tnikkel) → review+
Comment 15•8 years ago
|
||
Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/3d3834cc0e36
Comment 17•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/293229046bc2
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Comment 18•8 years ago
|
||
[Tracking Requested - why for this release]: in order to get this on the radar of relman, since this is a regression & crasher in 46 that might have an upliftable fix. in 46.0b5 this crash makes up ~0.2% of all crashes.
tracking-firefox46:
--- → ?
Comment 19•8 years ago
|
||
I missed this last week. Thanks Philipp. Yes, I think we could still uplift this to 47 and for 46 beta 11. Matt can you request uplift if you think that's a good idea and not too risky?
status-firefox47:
--- → affected
tracking-firefox47:
--- → +
tracking-firefox48:
--- → +
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 20•8 years ago
|
||
Comment on attachment 8734213 [details] [diff] [review] perspective-crash Approval Request Comment [Feature/regressing bug #]: Bug 1168263 [User impact if declined]: Crashes when doing selections of 3d transforms. [Describe test coverage new/current, TreeHerder]: Manually tested. [Risks and why]: Very low risk, just adds a null check. [String/UUID change made/needed]: None.
Flags: needinfo?(matt.woodrow)
Attachment #8734213 -
Flags: approval-mozilla-beta?
Attachment #8734213 -
Flags: approval-mozilla-aurora?
Comment 21•8 years ago
|
||
Comment on attachment 8734213 [details] [diff] [review] perspective-crash Crash fix, manual testing, let's take this for aurora and beta. This should end up in beta 11 later in the week.
Attachment #8734213 -
Flags: approval-mozilla-beta?
Attachment #8734213 -
Flags: approval-mozilla-beta+
Attachment #8734213 -
Flags: approval-mozilla-aurora?
Attachment #8734213 -
Flags: approval-mozilla-aurora+
Comment 22•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/ad52021053bf
Comment 23•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/75957f20740f
Updated•8 years ago
|
Flags: qe-verify+
Comment 24•8 years ago
|
||
I've managed to reproduce this bug on Windows 10 x64 using the testcase from Comment 9 with 46.0a2 (2016-03-02). This is confirmed fixed on Windows 10 x64 and Windows 7 x64, using: * 46.0b11-build1 (20160414152344), * 47.0a2 (2016-04-17), * 48.0a1 (2016-04-17). Socorro points to the same status, with 0 crashes for Fx 46.0b11 in the last 3 days.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•