1337776 - Crash in OOM | large | mozglue.dll@0x2b23

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: bughunter stack

This bug was filed from the Socorro interface and is 
report bp-d44abe4f-1a11-4d19-b0e4-2d32f2170208.
=============================================================

found via bughunter on http://library.um.ac.id/free-contents/new-karyailmiah/search.php/Skripsi%2C.php - steps to reproduce:

-> Load http://library.um.ac.id/free-contents/new-karyailmiah/search.php/Skripsi%2C.php and wait
---> OOM Crash on Windows

Comment 1

[Carsten Book [:Tomcat]]

glandium: do you know who could take a look at this ?

Comment 2

[Mike Hommey [:glandium]]

Available Virtual Memory 	364,630,016 bytes (347.74 MB)
Available Physical Memory 	71,364,608 bytes (68.06 MB)
OOM Allocation Size 	213,909,504 bytes (204 MB)

With only 350MB free virtual memory, it's not surprising that it's hard to allocate 204MB of contiguous memory, so this is a straightforward OOM. It's weird that the crash doesn't have symbols...

The question is whether the page itself is being crazy with memory usage or if there's something inherently wrong with Firefox.

When loading the page on my machine, CPU skyrockets, as well as memory usage. After a minute or so, with the page still with a spinner, this is what about:memory says about it:

│  ├──2,431.15 MB (29.99%) -- top(http://library.um.ac.id/free-contents/new-karyailmiah/search.php/Skripsi%2C.php, id=2147487653)
│  │  ├──2,430.76 MB (29.99%) -- active
│  │  │  ├──2,430.62 MB (29.99%) -- window(http://library.um.ac.id/free-contents/new-karyailmiah/search.php/Skripsi%2C.php)
│  │  │  │  ├──1,593.55 MB (19.66%) -- dom
│  │  │  │  │  ├──1,174.19 MB (14.49%) ── element-nodes
│  │  │  │  │  ├────387.33 MB (04.78%) ── text-nodes
│  │  │  │  │  └─────32.03 MB (00.40%) ++ (4 tiny)
│  │  │  │  ├────788.91 MB (09.73%) -- layout
│  │  │  │  │    ├──509.67 MB (06.29%) -- frames
│  │  │  │  │    │  ├──316.07 MB (03.90%) ── nsTextFrame
│  │  │  │  │    │  ├──170.31 MB (02.10%) ── nsInlineFrame
│  │  │  │  │    │  └───23.29 MB (00.29%) ++ (11 tiny)
│  │  │  │  │    ├──211.38 MB (02.61%) ── pres-contexts
│  │  │  │  │    └───67.86 MB (00.84%) ++ (7 tiny)
│  │  │  │  └─────48.16 MB (00.59%) ++ (3 tiny)
│  │  │  └──────0.14 MB (00.00%) ++ window(about:blank)
│  │  └──────0.40 MB (00.00%) ++ (2 tiny)

Also, this is worrying:
├──4,133.53 MB (50.99%) ── heap-unclassified

Closing the tab makes those numbers go down (including heap-unclassified)

So it would seem someone from layout/dom should look into this (trying bz, but feel free to redirect). And maybe Nick can take a look at the heap-unclassified stuff with DMD.

Comment 3

[Boris Zbarsky [:bzbarsky]]

There isn't that much to look into, actually.  If you curl/wget/whatever that URL, you will see that it's about 654MB of HTML.  Normally I expect the DOM to end up taking about 10x the memory of the HTML source, so you were probably 1/3 of the way through loading this or so... ;)

That said, the 200MB allocation is not _totally_ expected given what I see on the page (which is just lots of DOM nodes), and the really high heap-unclassified is indeed worrying.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So I tried crashing in a 32-bit Mac build, just to see what the stack would be like.  I got https://crash-stats.mozilla.com/report/index/1e0c37b7-9f85-49c7-838b-af15f2170209 which is an oom on a 176-byte allocation.  Which is more like what I expect on this page...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Tried it a few more times and got some large alloc crashes now:

https://crash-stats.mozilla.com/report/index/eca95a9b-4113-4545-9cbb-865032170209
https://crash-stats.mozilla.com/report/index/b6ee7c15-94e3-418f-8b89-4fc812170209
https://crash-stats.mozilla.com/report/index/9c28e21b-a17d-4c8c-9123-3df2f2170209
https://crash-stats.mozilla.com/report/index/7e9a40a8-dbdf-48ae-b432-d3e5a2170209
https://crash-stats.mozilla.com/report/index/e17fbe7f-aab0-4186-971d-e128b2170209

These are all ensuring nsTArray capacities under nsHtml5TreeBuilder::appendElement or nsHtml5TreeBuilder::createElement or nsHtml5TreeBuilder::appendCharacters with multi-hundred-megabyte allocations.

All of those functions do mOpQueue.AppendElement() when parsing off-thread.  It's possible we're going long enough between parser flushes that our op queue gets to be big enough to OOM.  This is an array of nsHtml5TreeOperation structs.  Each struct is 6 words, as far as I can tell, so 24 bytes on a 32-bit system.  So we've got an op queue with ~10 million elements in it when we crash.  There are almost 14 million '<' chars in this file, so we're going to have that many ops just for all the element creations, plus that many again for all the inserts, plus whatever happens with attributes, etc.

I'm not sure whether we want to prevent the op queue from getting too long like this, in general....

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #5)
> I'm not sure whether we want to prevent the op queue from getting too long
> like this, in general....

Forcing a flush immediately before an OOMing mOpQueue.AppendElement() would add too much complexity.

I guess we could
 a) After tokenizing a buffer check if the op queue is very long and flush if so.
or
 b) Make the op queue use FallibleTArray, check for failure upon each append and mark the parser as broken on failure.

bz, do you see value in doing a)? I'm guessing it would likely just move the OOM elsewhere.

Comment 7

[Boris Zbarsky [:bzbarsky]]

It's hard to say.  The problem with the current setup is that _fragmentation_ can kill us, not actual low memory, because we're asking for a huge array.  But yes, it's possible we would just end up with OOM for real if we went ahead and built that DOM tree.

If (b) is workable and not too much of a perf hit, it might be good to do that, though.

Comment 9

[Nicholas Nethercote [inactive]]

Attachment: DMD output

I did a DMD run. I think it's just confirming the analysis from comment 5 and comment 6.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.