977902 - Can we call nsMemoryInfoDumper::DumpMemoryInfoToTempDir in a content process?

Status: RESOLVED INVALID

(Toolkit :: about:memory, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Bug 969415 sees us calling nsMemoryInfoDumper::DumpMemoryInfoToTempDir on the occasion of a JS OOM:

https://hg.mozilla.org/mozilla-central/diff/b677573f964b/js/xpconnect/src/XPCJSRuntime.cpp#l1.44

If this can happen in a content process, then that's bad; sandboxing will crash the process, as in bug 946407.  We'd need to message the parent to ask for report (which uses memory, but so do the memory reporters, so hopefully we have some headroom).

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This might still be relevant on desktop.  If it is, we'd probably be returning an error rather than crashing; and, as the comment in XPCJSRuntime.cpp (linked above) mentions, this would cause the memory dump to silently fail.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

On further thought, this could be broken on all three main desktop platforms (if it's broken at all).

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This should be not-a-bug on desktop — the file is written to NS_OS_TEMP_DIR, as looked up in the content process, which will be a directory that the content process can write to at that time.  However, I haven't tested this.

Also, the UI for this feature is to set a pref in about:config, reproduce the OOM, and then manually look for the memory dump; there isn't anything in the parent process that might be looking for the files in the wrong place (TmpD vs. ContentTmpD).

So this is WONTFIX on B2G and INVALID on desktop.