Closed Bug 1238928 Opened 4 years ago Closed 4 years ago

crash in nsDisplayPerspective::BuildLayer


(Core :: Layout, defect, critical)

Not set



Tracking Status
firefox46 + verified
firefox47 + verified
firefox48 + verified


(Reporter: mstange, Assigned: mattwoodrow)



(Keywords: crash, regression, testcase)

Crash Data


(4 files)

This bug was filed from the Socorro interface and is 
report bp-68c8b17f-1e83-4b61-a93c-727f12160112.

I was on (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.
I haven't been able to reproduce this yet, and it's not obvious what is wrong from the crash report.
Blocks: 1168263
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 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.
(Note: my first crash report has e10s disabled, my second one has it enabled.)
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.
Attached file gdb backtrace of crash
(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 {
      top: 0;  
      left: 80px; 
      -webkit-perspective: 800px;
      perspective: 800px;
      transform-origin: 50% 20%;

* I'm attaching a GDB backtrace, and I'll attach a frame dump, too, for completeness.
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.
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.
Attached file testcase 1
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.
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
Reproduces for me on mac. Display lists for drawing selections are unusual beasts.
Regression range, using mozregression:

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: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Attachment #8734213 - Flags: review?(tnikkel)
Attachment #8734213 - Flags: review?(tnikkel) → review+
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
[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.
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?
Flags: needinfo?(matt.woodrow)
Comment on attachment 8734213 [details] [diff] [review]

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 on attachment 8734213 [details] [diff] [review]

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+
Flags: qe-verify+
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.
You need to log in before you can comment on or make changes to this bug.