Open Bug 1612799 Opened 9 months ago Updated 2 months ago

Crash in [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk]

Categories

(Core :: Gecko Profiler, defect, P3)

Unspecified
Windows 10
defect

Tracking

()

People

(Reporter: gsvelto, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-2b10eba0-0e04-4b10-9aa9-9c77b0200203.

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 ChunkedJSONWriteFunc::AllocChunk tools/profiler/core/ProfileJSONWriter.cpp:84
4 xul.dll SpliceableChunkedJSONWriter::SpliceableChunkedJSONWriter tools/profiler/public/ProfileJSONWriter.h:115
5 xul.dll profiler_get_profile tools/profiler/core/platform.cpp:3799
6 xul.dll mozilla::ProfilerChild::GrabShutdownProfile tools/profiler/gecko/ProfilerChild.cpp:114
7 xul.dll mozilla::ChildProfilerController::ShutdownProfilerChild tools/profiler/gecko/ChildProfilerController.cpp:93
8 xul.dll mozilla::detail::RunnableMethodImpl<RefPtr<mozilla::AbstractCanonical<RefPtr<AudioDeviceInfo> > >, void  xpcom/threads/nsThreadUtils.h:1215
9 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220

This is an OOM crash happening in the profiler code when a content process is shutting down. The allocation triggering the crash is rather large (2MiB) which is surprising because it seems that the code is just writing out JSON code.

Maybe this can involve a lot of JSON code? Is it possible to fail gracefully here instead of going OOM?

If this is not actionable please go ahead and close this as WONTFIX.

The Profiler can indeed generate big JSON strings, and at that time they coexist with the big Profiler raw buffer, increasing the odds of OOMs!

But we should definitely be able to handle most OOMs. I'll keep this bug (focusing on JSON generation) as a dependency of bug 1558402.

In the meantime, you may be able to lessen the occurrences by reducing the Profiler buffer size (controlled through the add-on or Nightly's built-in popup), of course at the cost of recording a smaller window of time.

Blocks: 1558402
Priority: -- → P3

Super-silly question, could this JSON be streamed out incrementally without using large buffers? We had a couple more bugs like this one which we fixed by streaming out data to disk but not being familiar with the code here I don't know if it's possible.

That JSON is later sent to the web client js code (from https://profiler.firefox.com) in the same Firefox, so I'm afraid it will stick around in memory anyway -- and it can be multi-MB big!
But there are probably options that could help. As you suggested, we could stream the generated JSON to disk, then clean up the Profiler data, and later stream the JSON out of disk to the Profiler client. There are big plans for the future! 😉

Crash Signature: [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk] → [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk] [@ OOM | large | mozalloc_abort | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk ]
Crash Signature: [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk] [@ OOM | large | mozalloc_abort | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk ] → [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk] [@ OOM | large | mozalloc_abort | moz_xmalloc | ChunkedJSONWriteFunc::AllocChunk ] [@ OOM | large | mozalloc_abort | moz_xmalloc | mozilla::baseprofile…
You need to log in before you can comment on or make changes to this bug.