1591276 - Crash in JSRuntime::onOutOfMemory on http://unmatchedstyle.com/news/height-based-media-queries.php

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Hiroyuki Ikezoe (:hiro)]

bp-96c398a7-5476-4c5a-b74f-64eae0191024

I don't know whether there are something we can do, and I don't know what the site actually does, but the site certainly kills Firefox nightly...

Comment 1

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

The priority flag is not set for this bug.
:glandium, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Florencia Di Ciocco, NI to vbalducci]

Hi Mike, would you happen to know which is the most appropriate component for this issue? Thanks!

Comment 3

[Andrew McCreight (out of office until 8/21) [:mccr8]]

It isn't possible to tell why we're using a lot of memory without further information.

The first step would be to get an about:memory report for this page. I tried, but the memory reporter just hung during the process.

Comment 4

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

Thanks for the details. I was able to reproduce on Windows 10, on Firefox Nightly version 73.0a1 (2019-12-23) (64-bit), beta 72.0b10 (64-bit), and firefox release 71.0.

I've chosen a component so that the issue is reviewed.

Best regards, Clara.

Comment 5

[Sean Feng [:sefeng211]]

Since it's a crash, pass it along to the js team.

Comment 6

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I've tested this using the latest Nightly version 74.0a1 (2020-01-09) (64-bit) for Windows 10 pro and I’m able to reproduce the issue. Based on this I will mark firefox74 flag as affected as well.

Best,
Clara

Comment 7

[Jon Coppeard (:jonco)]

Any idea why this is crashing in jemalloc rather that returning null as expected?

Comment 8

[Mike Hommey [:glandium]]

There are few places that MOZ_CRASH() in mozjemalloc, and even less that do so without a message. This one comes from pages_decommit in InitChunk. https://hg.mozilla.org/mozilla-central/annotate/ad7a152bc66c0d411a6fb0b210d675abed9693c7/memory/build/mozjemalloc.cpp#l1297
Bug 1539133 would change the signature to be more explicit, but in this particular crash, it means mmap fails either because of address space exhaustion or because of the number of mappings exceeding 32K. At least that would be the explanation for Linux. For Windows, I'm not sure why VirtualFree would fail in the corresponding code. https://hg.mozilla.org/mozilla-central/annotate/ad7a152bc66c0d411a6fb0b210d675abed9693c7/memory/build/mozjemalloc.cpp#l1288
Do we have crash reports for Windows?

Comment 9

[Jon Coppeard (:jonco)]

(In reply to Mike Hommey [:glandium] from comment #8)
Yes, there are a few with this signature:

https://crash-stats.mozilla.org/signature/?product=Firefox&signature=arena_t%3A%3AAllocRun%20%7C%20BaseAllocator%3A%3Amalloc%20%7C%20replace_moz_arena_malloc&date=%3E%3D2019-10-14T18%3A28%3A00.000Z&date=%3C2020-01-14T18%3A28%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

Comment 10

[Mike Hommey [:glandium]]

The Windows crashes are on a different line of code in the same function, so they're not the same thing at all. They suggest allocator metadata corruption.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

I just tried open the site in question on Windows 10 (32GB), it doesn't cause the crash at all. It repeatedly shows "script makes the browser slow" (This is not correct words since it's written in Japanese).

Comment 12

[Hiroyuki Ikezoe (:hiro)]

After a while I noticed there is an unsent crash report which seems to happened after closing the tab for the site. FWIW, bp-1c0844f2-952b-4866-b12c-af5c40200114

Comment 13

[Jon Coppeard (:jonco)]

We're coming through this path because we're retrying an allocation after hitting OOM. As per comment 3 this looks like a crash caused by OOM in jemalloc. I'm not sure what we can do here.

Comment 14

[Steven DeTar [:sdetar]]

Jon, is there someone we can assign this to look at on another team? Or is this just not actionable at this time. I would like to identify what the next steps are with this bug if possible. I have moved it to a P2 until we figure out what to do with it.

Comment 15

[Jon Coppeard (:jonco)]

Sorry for being slow picking this up. TBH I didn't realise how easy this was to reproduce.

about:memory shows that nursery-malloced-buffers grows very large very quickly (to 10s of GB on my machine).

It seems the page is doing something like:

let str = "";
for (;;) {
  str = "foobar" + str.substring(1);
  str.indexOf("?");
}

It's repeatedly creating a rope and then flattening it (by calling indexOf). This copies the string contents to a new buffer every time so we end up tons of nursery allocated strings with increasingly large buffers attached. These buffers are malloc allocated, and we don't track the memory usage of these at the moment.

Comment 16

[Jon Coppeard (:jonco)]

Attachment: Bug 1591276 - Refactor code to reallocate malloced buffers associated with nursery cells r?sfink

Comment 17

[Jon Coppeard (:jonco)]

Attachment: Bug 1591276 - Track memory used by malloced buffers associated with nursery cells r?sfink

This tracks the total memory used by the nursery's malloced buffers set and trigers a minor GC if it passes some limit. The limit is somewhat arbirarily defined as eight times the nursery capactity - this only fires rarely in normal use but is enough to prevent runaway memory growth in this case.

Depends on D71041

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3309177cef0a
Refactor code to reallocate malloced buffers associated with nursery cells r=sfink
https://hg.mozilla.org/integration/autoland/rev/ddca597d13b1
Track memory used by malloced buffers associated with nursery cells r=sfink

Comment 19

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/3309177cef0a
https://hg.mozilla.org/mozilla-central/rev/ddca597d13b1

Comment 20

[Anca Soncutean, Desktop QA]

I wasn't able to reproduce the crash, Clara Guerrero, can you please confirm the fix on the latest Beta?

Comment 21

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I've tested this using Release 76.0 (64-bit), Beta 77.0b8 (64-bit), Firefox Nightly 78.0a1 (2020-05-28) (64-bit) for mac OS 10.14, windows 10 pro and ubuntu 18.04 and I’m also not able to reproduce the crash anymore. Based on this I will mark each respective flag as verified and the bug's status to verified:fixed. Removing qe-verify+ as well.

Best,
Clara