1688271 - Crash in [@ OOM | small]

Status: RESOLVED DUPLICATE of bug 1673778

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

Description

[Worcester12345]

Crash report: https://crash-stats.mozilla.org/report/index/dee0cd01-6ae0-46ce-b51a-2a3ca0210121

MOZ_CRASH Reason: MOZ_CRASH()

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:54
3 xul.dll NS_CycleCollectorSuspect3 xpcom/base/nsCycleCollector.cpp:3761
4 xul.dll nsDOMMutationObserver::CurrentRecord dom/base/nsDOMMutationObserver.cpp:918
5 xul.dll nsMutationReceiver::ContentInserted dom/base/nsDOMMutationObserver.cpp:274
6 xul.dll static mozilla::dom::MutationObservers::NotifyContentInserted dom/base/MutationObservers.cpp:186
7 xul.dll nsINode::ReplaceOrInsertBefore dom/base/nsINode.cpp:2720
8 xul.dll mozilla::dom::Node_Binding::insertBefore dom/bindings/NodeBinding.cpp:929
9  @0x283871a4ef4 

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It's the line to create a record.
https://searchfox.org/mozilla-central/rev/4f07d49f1c7a823da07e3a231ac87c6435c8fd58/dom/base/nsDOMMutationObserver.cpp#918-919

Even though looks like there is enough memory space in the system, but the OOM could be caused by memory fragment or something.

glandium-san, do you have any ideas?

Comment 2

[Mike Hommey [:glandium]]

It could also be VirtualAlloc returning null (too many mappings or something? Such things happen on Linux...). I don't think we record the amount of mapped memory in the crashing process in crash report, do we, Gabriele?

Comment 3

[(Away)]

In !vadump I see 16762 regions (15781 mappings that aren't MEM_FREE -- maybe the free regions aren't actually stored) which is way more than usual. I wouldn't be surprised if there were a cap at 16k or something.

Comment 4

[Gabriele Svelto [:gsvelto]]

The VirtualAlloc() page in Microsoft documentation doesn't specify the failure modes so it's hard to tell what might be going on. It might be worth in this scenario to call GetLastError() and store the result in a crash annotation.

Comment 5

[(Away)]

It might be worth in this scenario to call GetLastError() and store the result in a crash annotation.

If you can find this happening in a Nightly minidump, you can view GetLastError() with !gle, but we currently don't save it on other channels: https://searchfox.org/mozilla-central/rev/3ff133d19f87da2ba01ade55d6e7fdf0fc28b08c/toolkit/crashreporter/nsExceptionHandler.cpp#1736-1739.

Comment 6

[Gabriele Svelto [:gsvelto]]

Oh, that's extremely useful! Do you know in what section of the minidump it gets stored? This is the kind of stuff that I'd love to surface in Socorro.

Comment 7

[(Away)]

It comes from the TEB, but then the next question is where is that stored, which I don't know. :-)

0:000> !gle
LastErrorValue: (Win32) 0x12a (298) - Too many posts were made to a semaphore.
[...]
0:000> !teb
TEB at 000000ea4b5f6000
[...]
0:000> dt nt!_TEB 000000ea4b5f6000
[...]
   +0x068 LastErrorValue   : 0x12a

Comment 8

[Gabriele Svelto [:gsvelto]]

There's a pointer in the thread status. I'll file a bug to surface this stuff in Socorro. This is going to be super-useful.

Comment 9

[Mirko Brodesser (:mbrodesser-Igalia), offline until 10th of Feb]

(In reply to Gabriele Svelto [:gsvelto] from comment #8)

There's a pointer in the thread status. I'll file a bug to surface this stuff in Socorro. This is going to be super-useful.

When filed, please link it to this ticket.