1507410 - Crash in OOM | large | NS_ABORT_OOM | nsGenericHTMLElement::GetURIAttr

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-98e94876-8217-4fd7-9e85-9265e0181115.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll NS_ABORT_OOM xpcom/base/nsDebugImpl.cpp:628
1 xul.dll nsGenericHTMLElement::GetURIAttr dom/html/nsGenericHTMLElement.cpp:1517
2 xul.dll static bool mozilla::dom::HTMLImageElement_Binding::get_src dom/bindings/HTMLImageElementBinding.cpp:178
3 xul.dll mozilla::dom::binding_detail::GenericGetter<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3172
4  @0x2eba00f1 
5 mmdevapi.dll _CxxThrowException 
6 xul.dll [thunk]:nsContentList::Length`adjustor{72}'  
7 xul.dll js::num_toString js/src/jsnum.cpp:778
8  @0x1ae9a7 
9  @0x2e9654f1 

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

this crash signature is spiking up since yesterday on 32bit windows installations and android. the spike is limited to cs builds and all the comments point towards performing actions on some online banking service (George - george.cz).

there were 1000 crash reports processed yesterday, which is accounting for three quarters of all content crashes from cs builds.

Comment 1

[Jan Dvořák]

Hello, as a part of George support team, I must say this issue is very critical for us, some clients can't login to their internetbanking using FF. Can you confirm that issue is directly in Firefox browser? Is there something we can say to our clients except of "use another web browser"? Regarding to graph in details of this bug, it seems problem is detected since Semptember 5th, when was Firefox 62 released.

Can you recommend us any changes we can make on our side to prevent these crashes?

Thank you.

Comment 2

[[:philipp]]

the graph in the bug report is lagging behind for two days unfortunately. the real-time graph is at https://crash-stats.mozilla.com/signature/?signature=OOM%20%7C%20large%20%7C%20NS_ABORT_OOM%20%7C%20nsGenericHTMLElement%3A%3AGetURIAttr#graphs so the issue obviously started getting much worse yesterday. if you deployed any changes in that timeframe it may be worth looking at those or reverting them for the moment.

in regards to the technical questions you were asking, i'm not the right person to answer but i'll try to escalate it and hope someone will get back to you quickly.

Comment 3

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

Is there some way to reproduce this?

Comment 4

[Jan Dvořák]

Thank you for prompt reply, easiest way to reproduce this problem below:
1) enter website george.csas.cz - you're redirected to URL: https://bezpecnost.csas.cz/flfe/?client_id=georgeclient_cz
2) spent some time on this site, you can type something to field Client number / Username
3) crash appears (sometimes it takes just few seconds, sometimes it takes few minutes)

I reproduced this on android device (Samsung Galaxy S8), but should be reproducible on WIN 32-bit as well.

Comment 5

[Jan Dvořák]

any updates? did you try to reproduce this issue and investigate where could be problem? Thank you.

Comment 6

[Pascal Chevrel:pascalc (PTO until April 26)]

Wontfix for 63 as we are unlikely to have another dot release before 64 ships in 3 weeks from now, tracking for 64.

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

Cornel, could your team find the regression range for this bug? Thanks!

Comment 8

[[:philipp]]

i think it's not a real regression but a signature shift as i'm also able to reproduce oom crashes on the login page of this bank with older versions of firefox.

Comment 9

[[:philipp]]

Attachment: memory-report.json.gz

snapshot from about:memory after opening https://bezpecnost.csas.cz/flfe/?client_id=georgeclient_cz and letting it sit for a bit.

Comment 10

[Andrew McCreight [:mccr8]]

Thanks for the memory report. It has 1.1GB or so of strings. Most of that is images encoded as data URIs.

Comment 11

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I managed to manually look for a regression range for this issue, on the mentioned affected platforms - it is reproducible starting with 63.0a1 (20180707100052), when [@ OOM | large | NS_ABORT_OOM | AppendUTF8toUTF16 | mozilla::dom::HTMLImageElement_Binding::get_src ] occured (see the related crash report https://crash-stats.mozilla.com/report/index/5aa49d9f-1c62-40df-b14d-3f8ad0181121).

Comment 12

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Forgot to provide a pushlog for the above mentioned regression range. Here it is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fa376bf17cc9&tochange=9849ea3937e2.

Comment 13

[Henri Sivonen (:hsivonen)]

FWIW, the changes to AppendUTF8toUTF16() since August should not have changed the memory requirements for the ASCII case, which is the case data: URLs should exercise.

Comment 14

[Jan Dvořák]

On last Friday we downsized images that are used on login page (carousel rotating next to the username field), regarding to graph of crashes workaround works.

Comment 15

[Julien Cristau [:jcristau] (back April 22)]

wontfix for 64 at this point, looks like the big spike was stopped by the site change in comment 14.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Low volume crash, has a priority set. 
Marking fix-optional to remove this from regression triage. 
Happy to still take a patch in nightly.

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Low volume crash, the big spike stopped since comment 14. wontfix for 65 at the late cycle.

Comment 18

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on Windows 10 and 7 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-16), beta 86.0 and release 85.0.2. No crashes occur for the given site.

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.