1437662 - Crash in OOM | large | NS_ABORT_OOM | nsDataHandler::NewURI

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect, P2)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-2e44d2fe-f2a8-445a-aedd-c9bb70180212.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:620
1 xul.dll nsDataHandler::NewURI netwerk/protocol/data/nsDataHandler.cpp:69
2 xul.dll mozilla::net::nsIOService::NewURI netwerk/base/nsIOService.cpp:697
3 xul.dll NS_NewURI netwerk/base/nsNetUtil.cpp:1787
4 xul.dll mozilla::css::URLValueData::GetURI layout/style/nsCSSValue.cpp:2950
5 xul.dll mozilla::css::URLValueData::HasRef layout/style/nsCSSValue.cpp:2984
6 xul.dll nsStyleImageRequest::Resolve layout/style/nsStyleStruct.cpp:2200
7 xul.dll mozilla::ServoStyleContext::ResolveSameStructsAs obj-firefox/dist/include/nsStyleStructList.h:83
8 xul.dll mozilla::ServoRestyleManager::ProcessPostTraversal layout/base/ServoRestyleManager.cpp:885
9 xul.dll mozilla::ServoRestyleManager::ProcessPostTraversal layout/base/ServoRestyleManager.cpp:952

=============================================================

this crash signature is newly appearing in firefox 58 and subsequent versions on
32bit builds on windows. most of the time it's the content process that's crashing here.

Comment 1

[Mike Taylor [:miketaylr]]

Volume seems low enough to wontfix for 58.

Comment 2

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P2 ] P2 bugs may become P1's after further analysis. Please prioritize diagnosis and repair.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Still low-frequency, but still hanging around on 60. Emilio, is this bug in the right component or should it be moved over to Networking?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Well, kind of... This all happens on style / layout code. We're resolving 0.5MB data URIs which cause a OOM. Not sure there's much actionable here, but probably it should live here, yes.

Comment 5

[Mats Palmgren (inactive)]

Crashing on OOM is the proper way to handle this.  We could try to avoid it
by not displaying the image (dataloss - bad) but the content process is likely
going to crash somewhere else soon after anyway (perhaps in a less secure way).