Closed
Bug 1302082
Opened 8 years ago
Closed 7 years ago
[e10s] Crash in nsPresContext::GetParentPresContext or nsPresContext::GetRootPresContext
Categories
(Core :: Layout, defect, P1)
Tracking
()
RESOLVED
DUPLICATE
of bug 1261175
People
(Reporter: philipp, Unassigned)
Details
(4 keywords)
Crash Data
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•8 years ago
|
||
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'.
Reporter | ||
Comment 2•8 years ago
|
||
(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•8 years ago
|
||
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•8 years ago
|
||
Jet, this sounds pretty bad, can you find an owner?
Flags: needinfo?(bugs)
Priority: -- → P1
Comment 5•8 years ago
|
||
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•8 years ago
|
||
(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?
Flags: needinfo?(bugs) → needinfo?(jmathies)
Comment 8•8 years ago
|
||
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
status-firefox-esr45:
--- → affected
Updated•8 years ago
|
Reporter | ||
Comment 9•7 years ago
|
||
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
Group: core-security
Crash Signature: [@ nsPresContext::GetParentPresContext] → [@ nsPresContext::GetParentPresContext]
[@ nsPresContext::GetRootPresContext ]
status-firefox52:
--- → affected
status-firefox53:
--- → affected
Keywords: regression
Reporter | ||
Updated•7 years ago
|
Keywords: regression
Comment 10•7 years ago
|
||
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.
Group: core-security → layout-core-security
Summary: [e10s] Crash in nsPresContext::GetParentPresContext → [e10s] Crash in nsPresContext::GetParentPresContext or nsPresContext::GetRootPresContext
Comment 11•7 years ago
|
||
I think this bug is a dupe of bug 1261175, i.e. a call from nsRefreshDriver::IsWaitingForPaint that crashes in GetRootPresContext / GetParentPresContext.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Updated•5 years ago
|
Group: layout-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•