1280181 - [e10s] Crash in nsTextFrame::AddInlineMinISizeForFlow when printing

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[[e-mail]]

This bug was filed from the Socorro interface and is 
report bp-2ebae714-323f-4035-927c-894f42160615.
=============================================================

When e10s is on, print a page will crash the tab.

Comment 1

[[e-mail]]

since nsTextFrame is changed in 1278014, add it to block list

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to [e-mail] from comment #1)
> since nsTextFrame is changed in 1278014, add it to block list

It replaces raw int value to enum class items. So, shouldn't cause such stack's crash. Are you sure if it really causes this bug?

Comment 3

[[e-mail]]

I'm not sure. But adding bug 1278014 to the block list is a way to call the exports to make the conclusions.

Comment 4

[Loic]

I got 2 different crash signatures, when printing with e10s enabled:
1) https://www.mozilla.org/en-US/firefox/nightly/firstrun/
https://crash-stats.mozilla.com/report/index/e399989e-abbe-4c4a-b6fe-1e5662160615

2) https://bugzilla.mozilla.org/
https://crash-stats.mozilla.com/report/index/5a71c37c-6f21-4478-b479-60ff22160615

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c89b8cc657b20d8f854585f10020afcaa001d1bf&tochange=1bd6da31483db28d8fd65a0ef69d8dfe42cb0f0f

Jonathan Watt — Bug 1279654 - Create a PrintTargetRecording subclass of PrintTarget. r=mstange

Comment 5

[Jonathan Watt [:jwatt]]

That is...weird. The patch for bug 1279654 should not affect layout at all. I'm not sure how that could possibly result in those stack traces. How sure are you about the regression range?

Comment 6

[Loic]

Yeas, I tested twice (one time for each webpage). Maybe your patch has triggered a bug in the layout component with e10s on.

Comment 7

[Jonathan Watt [:jwatt]]

(In reply to Loic from comment #6)
> Yeas, I tested twice (one time for each webpage).

Which page?

> Maybe your patch has
> triggered a bug in the layout component with e10s on.

I don't see how that's possible, since it doesn't affect layout. I'll need to get my hands on a Windows 10 machine.

Comment 8

[Loic]

(In reply to Jonathan Watt [:jwatt] from comment #7)
> (In reply to Loic from comment #6)
> > Yeas, I tested twice (one time for each webpage).
> 
> Which page?

See https://bugzilla.mozilla.org/show_bug.cgi?id=1280181#c4

Comment 9

[Jonathan Kew [:jfkthame]]

FWIW, the crash address is 0x54 in both cases, which sounds very much like it's trying to dereference the mDT field of a null gfxContext ptr. So where's that coming from?

Comment 10

[Jonathan Watt [:jwatt]]

(In reply to Loic from comment #8)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=1280181#c4

Ah, thanks. When I initially saw that comment it was in an email body where it was broken over several lines and the link was broken. When I subsequently saw it in the bugzilla comment my brain processed that as one link to crash report rather than two different links on adjacent lines. Tired...

Comment 11

[Jonathan Watt [:jwatt]]

Also I've now figured out how this patch can go wrong.

Comment 12

[Jonathan Watt [:jwatt]]

I'll work on fixing bug 1280324 in the morning (otherwise we'll have to back out the changes to nsDeviceContextSpecProxy.cpp from bug 1279654, bug 1279790 and bug 1279789).

Comment 13

[Marcia Knous [:marcia]]

Tracking for 50+ - reproducible crash in printing.

Comment 14

[Nicholas Nethercote [inactive]]

This is #1 on Nightly by a mile, with close to 900 crashes, which is catastrophically higher than normal. jwatt, I understand that backing out is a pain but if a fix doesn't land very soon a backout should happen.

Comment 15

[Jonathan Watt [:jwatt]]

Ouch! Backing out...

Comment 16

[Carsten Book [:Tomcat]]

confimed the backout fix the problem.

Current nightly -> crash on the steps to reproduce

a tinderbox build with the fix like
http://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1466098702/
and the steps to reproduce -->>>> no crash \o/

Comment 17

[Milan Sreckovic [:milan] (needinfo for best results)]

Fixed with a backout.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

We still see this crash in 50.0b.
Milan, should we open a new bug for this? Thanks

Comment 19

[Jonathan Watt [:jwatt]]

It looks like there were crashes with this signature before the commit that caused this topcrash landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1279654#c3 . See:

https://crash-stats.mozilla.com/api/SuperSearch/?signature=~nsTextFrame%3A%3AAddInlineMinISizeForFlow&date=%3C2016-06-14&product=Firefox

So it looks like there is at least one other issue causing crashes in this frame that is unrelated to the issue this bug was filed for.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

So, we had this crash, then we got a lot more of it for a few days that bug 1279654 comment 3 patch was on central.  That patch is backed out, and we're back to the "we had this crash".
It sounds like bug 1279654 may get landed again once bug 1280324 lands.

We may as well keep this bug for the crash we're seeing.  It doesn't appear to be a topcrash anymore, nor do we have a reproducible case for it though, right?

Comment 21

[Milan Sreckovic [:milan] (needinfo for best results)]

This doesn't necessarily depend on bug 1280324, but it's worth looking at once that lands.

Comment 22

[Julien Cristau [:jcristau]]

Changing status to fix-optional for 50, since this isn't a top crash anymore.

Comment 23

[Jonathan Watt [:jwatt]]

This seems to be gone. In any case, since there's a bunch of discussion in this bug about one particular source of this crash, we should open a new bug for anything else otherwise bugs become more of a hassle to work on.