919156 - Crash in mozilla::layers::Layer::CalculateScissorRect(nsIntRect const&, gfxMatrix const*) with position:sticky enabled

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Boris Prpic]

Attachment: crash_page.zip

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20130921004001

Steps to reproduce:

1. Open Aurora and enable layout.css.sticky.enabled
2. Open attached page
3. Scroll list on the right
4. Crash
5. No Profit 


Actual results:

Crash


Expected results:

No crash

Comment 1

[Boris Prpic]

Crash: https://crash-stats.mozilla.com/report/index/01f79319-2d83-490e-9824-2dc5a2130921

Comment 2

[Kyle Wooten]

Thanks!

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Dbaron - who will be taking on these bugs now that Corey's internship is over?

Comment 4

[Corey Ford [:coyotebush]]

Sorry, I was supposed to help figure that out. This bug in particular looks like it would need someone working on D3D10 to debug it further. (I recall that I looked at the method in question and no potential null dereferences or such jumped out at me.)

Comment 5

[sjw]

It seems that Firefox crashs because the sticky element is in a fixed element.
If you remove L87 (position: fixed) in "Edit - Loudworks Casting.htm" from attachment 808156 [details] it works.

Comment 6

[Corey Ford [:coyotebush]]

So it's possible this is related somehow to bug 919434, though this one doesn't look like a stack overflow.

Comment 7

[sjw]

Attachment: crash scenario

I created another crash page without any content except the crash scenario.

1. enable layout.css.sticky.enabled
2. Scroll through text
3. Reload Page
4. Crash

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

position:sticky stayed back on Aurora so it should not be affecting FF26 anymore, untracking and ni? on KaiRo to confirm this is true in stats.

Comment 9

[Robert Kaiser]

I can't tell from data, as this is an extremely low-volume crash and actually most of the instances of this signature I'm seeing are in data are from releases like 23, 24, and 25, so it looks like position:sticky might just be triggering a crash that has been around for a while. In any case it looks like low volume on all channels.

Comment 10

[sjw]

=> FF28 affected

Is it normal that it doesn't crash if you view it in an iframe?

Comment 11

[Robert Kaiser]

This continues to be extremely low volume, I don't recommend tracking unless we intend to have sticky enabled through release on 28.

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Untracking, if this becomes a topcrasher can renom but otherwise just put an uplift nom on the patch when ready (and when sticky is truly shipping).

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

Should the test case in comment 7 trigger the crash every time or is this intermittent?  I can't seem to trigger it on a nightly from around Dec 2.

Comment 14

[sjw]

Seems fixed by 931460

Comment 15

[Loic]

(In reply to sjw from comment #14)
> Seems fixed by 931460

I don't think so.

Working range:
bad=2013-11-18
good=2013-11-19
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=beddd6d4bcdf&tochange=ba9ecdea3a90

My guess goes to:
Robert O'Callahan — Bug 919144. Part 10: Fold nsDisplayFixedPosition into nsDisplayStickyPosition. r=mattwoodrow