1674989 - Crash in [@ OOM | large | NS_ABORT_OOM | nsTSubstring<T>::Append | nsExpatDriver::ConsumeToken]

Status: NEW

(Core :: XML, defect, P3)

Description

[Simon Giesecke [:sg] [he/him]]

Crash report: https://crash-stats.mozilla.org/report/index/70c84be0-31df-49a5-adb6-fb9d00201101

MOZ_CRASH Reason: MOZ_CRASH(OOM)

Top 10 frames of crashing thread:

0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:618
1 xul.dll nsTSubstring<char16_t>::Append xpcom/string/nsTSubstring.cpp:830
2 xul.dll nsExpatDriver::ConsumeToken parser/htmlparser/nsExpatDriver.cpp:1055
3 xul.dll nsParser::ResumeParse parser/htmlparser/nsParser.cpp:960
4 xul.dll nsParser::OnDataAvailable parser/htmlparser/nsParser.cpp:1317
5 xul.dll mozilla::image::VectorImage::OnImageDataAvailable image/VectorImage.cpp:451
6 xul.dll imgRequest::OnDataAvailable image/imgRequest.cpp:1070
7 xul.dll ProxyListener::OnDataAvailable image/imgLoader.cpp:2881
8 xul.dll nsCORSListenerProxy::OnDataAvailable netwerk/protocol/http/nsCORSListenerProxy.cpp:627
9 xul.dll nsBaseChannel::OnDataAvailable netwerk/base/nsBaseChannel.cpp:876

There are several crashes with this signature (it's newly visible because Append wasn't on the prefix list before), but this reports has a really large allocation size of more than 80MB. Given it's on happening on an error handling path, it seems to me that this should be handled more gracefully.

Comment 1

[Simon Giesecke [:sg] [he/him]]

Adding a similar signature.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I guess this happens with very large SVG files.