1302082 - [e10s] Crash in nsPresContext::GetParentPresContext or nsPresContext::GetRootPresContext

Status: RESOLVED DUPLICATE of bug 1261175

(Core :: Layout, defect, P1)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-9cbbb18b-b71c-4522-9b88-1629a2160912.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsPresContext::GetParentPresContext() 	layout/base/nsPresContext.cpp:1061
1 	xul.dll 	nsPresContext::GetRootPresContext() 	layout/base/nsPresContext.cpp:1119
2 	xul.dll 	nsRefreshDriver::IsWaitingForPaint(mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:2085
3 	xul.dll 	nsRefreshDriver::Tick(__int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:1648
4 	xul.dll 	mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver*, __int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:274
5 	xul.dll 	mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) 	layout/base/nsRefreshDriver.cpp:246
6 	xul.dll 	mozilla::RefreshDriverTimer::Tick(__int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:265
7 	xul.dll 	mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:588
8 	xul.dll 	nsHtml5AttributeName::initializeStatics() 	parser/html/nsHtml5AttributeName.cpp:1742
9 	xul.dll 	Pickle::ReadBool(PickleIterator*, bool*) 	ipc/chromium/src/base/pickle.cc:162

this is the #3 crash in the content crash when i looked into data for 49 rc2. the issue seems to have started regressing in numbers during the whole 49 beta cycle and affects windows installations only.

Comment 1

[Mats Palmgren (inactive)]

There seems to be a sharp increase in volume around Aug 6.

I wonder if it's related to bug 1262027 in any way, because that bug
would be fairly easy to fix if we can capture it in 'rr'.

Comment 2

[[:philipp]]

(In reply to Mats Palmgren (:mats) from comment #1)
> There seems to be a sharp increase in volume around Aug 6.
this correlates with the time when 49.0b versions were first pushed to beta channel users.

Comment 3

[Mats Palmgren (inactive)]

It seems like this crash is much more common in e10s builds :-(
Of all reported crashes from 2016-08-01 til today about 70% have
"content" process type.  That seems alarming since the population
with e10s is relatively small so far (I assume).

Comment 4

[Jim Mathies [:jimm]]

Jet, this sounds pretty bad, can you find an owner?

Comment 5

[Benjamin Smedberg]

According to this query this is no longer in the content process topcrash list for 49:
https://crash-stats.mozilla.com/search/?product=Firefox&version=49.0&process_type=content&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Comment 6

[Jet Villegas (inactive)]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #5)
> According to this query this is no longer in the content process topcrash
> list for 49:
> https://crash-stats.mozilla.com/search/?product=Firefox&version=49.
> 0&process_type=content&_sort=-
> date&_facets=signature&_columns=date&_columns=signature&_columns=product&_col
> umns=version&_columns=build_id&_columns=platform#facet-signature

nsPresContext::GetParentPresContext is a very hot code path that I wouldn't expect to topcrash all of a sudden, and then just go away. Can we get some URLs from the dumps?

Comment 7

[Jim Mathies [:jimm]]

clearing this so it falls back into triage.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'nsPresContext::GetParentPresContext':
 - nightly (version 52): 0 crashes from 2016-09-19.
 - aurora  (version 51): 1 crash from 2016-09-19.
 - beta    (version 50): 2 crashes from 2016-09-20.
 - release (version 49): 332 crashes from 2016-09-05.
 - esr     (version 45): 1 crash from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       0
 - aurora        1       0
 - beta          2       0
 - release     285      47
 - esr           0       0

Affected platforms: Windows, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora            #1353
 - beta              #1537
 - release #1056     #43
 - esr

Comment 9

[[:philipp]]

it appears that the signature shifted from [@ nsPresContext::GetRootPresContext ] in firefox 48 to [@ nsPresContext::GetParentPresContext] in 49 and thenn back again since firefox 50.
apparently it's a UAF in most cases, so i will change the report to restricted as a precaution as well.

Correlations for Firefox Release:

(93.98% in signature vs 00.20% overall) address = 0xffffffffe5e5e5ed
(98.80% in signature vs 28.75% overall) Module "winspool.drv" = true [100.0% vs 23.00% if platform_pretty_version = Windows 10]
(99.20% in signature vs 34.69% overall) reason = EXCEPTION_ACCESS_VIOLATION_READ
(88.35% in signature vs 23.00% overall) process_type = content
Top words: print, connection', arggg, greatest, finger, advanc, hover, statement, side, wifi

Comment 10

[Daniel Veditz [:dveditz]]

Most of the time the crashing address is the pure poison value, but occasionally it's some random value which means it's possible an attacker could force this memory to be usefully re-used before the dangling pointer is de-referenced.

Comment 11

[Mats Palmgren (inactive)]

I think this bug is a dupe of bug 1261175, i.e. a call from nsRefreshDriver::IsWaitingForPaint
that crashes in GetRootPresContext / GetParentPresContext.