1543809 - Can't run with XPCOM_MEM_BLOAT_LOG=1 on OS X

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[Andrew McCreight [:mccr8]]

If I run
XPCOM_MEM_BLOAT_LOG=1 ./mach run
on OS X, then I immediately hit an assert:

Hit MOZ_CRASH(Failed to create or init an nsIFile) at /Users/amccreight/mc/xpcom/base/nsMacUtilsImpl.cpp:209
#01: mozilla::dom::ContentParent::AppendSandboxParams(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x38333b8]
#02: mozilla::dom::ContentParent::LaunchSubprocessInternal(mozilla::hal::ProcessPriority, mozilla::Variant<bool*, RefPtr<mozilla::MozPromise<RefPtr<mozilla::dom::ContentParent>, mozilla::ipc::GeckoChildProcessHost::LaunchError, false> >>&&)[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3833b52]
#03: mozilla::dom::ContentParent::GetNewOrUsedBrowserProcess(mozilla::dom::Element, nsTSubstring<char16_t> const&, mozilla::hal::ProcessPriority, mozilla::dom::ContentParent*, bool)[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3829056]
#04: mozilla::dom::ContentParent::CreateBrowser(mozilla::dom::TabContext const&, mozilla::dom::Element*, mozilla::dom::ContentParent*, mozilla::dom::TabParent*, unsigned long long)[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x382e47e]
#05: nsFrameLoader::TryRemoteBrowser()[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x194db11]
#06: nsFrameLoader::ShowRemoteFrame(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, nsSubDocumentFrame*)[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x194eeb7]
#07: nsFrameLoader::Show(int, int, int, int, nsSubDocumentFrame*)[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x195245b]
#08: nsSubDocumentFrame::ShowViewer()[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4198f25]
#09: AsyncFrameInit::Run()[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x41c98af]
#10: nsContentUtils::RemoveScriptBlocker()[/Users/amccreight/mc/obj-dbg.noindex/dist/NightlyDebug.app/Contents/MacOS/XUL +0x16d3efa]

[...]

It kind of sounds like a sandboxing issue, but BLOAT_LOG=1 should just be outputting to stdout. Also, I have no idea why AppendSandboxParams is trying to create an nsIFile, or why trying to make a bloat log would cause this code to run. We do create a bloat log for various tests, but that gets saved to a file in some directory tests are allowed to write to.

Comment 1

[Andrew McCreight [:mccr8]]

If I run with MOZ_DISABLE_CONTENT_SANDBOX=t, then it works, so it does feel like a sandbox issue of some sort.

Comment 2

[Andrew McCreight [:mccr8]]

I guess just disabling the sandbox is good enough for me.

Comment 3

[Bobby Holley (:bholley)]

Can you land a helpful notice pointing people to the workaround?

Comment 4

[Andrew McCreight [:mccr8]]

I don't know what is going wrong, so I'm not sure where such a notice would go.

Comment 5

[Eric Rahm [:erahm]]

(In reply to Andrew McCreight [:mccr8] from comment #4)

I don't know what is going wrong, so I'm not sure where such a notice would go.

Maybe mach run could check if you specify XPCOM_MEM_BLOAT_LOG and bail if sandboxing isn't disabled until we can figure out what's wrong.

Comment 6

[Bobby Holley (:bholley)]

(In reply to Eric Rahm [:erahm] from comment #5)

(In reply to Andrew McCreight [:mccr8] from comment #4)

I don't know what is going wrong, so I'm not sure where such a notice would go.

Maybe mach run could check if you specify XPCOM_MEM_BLOAT_LOG and bail if sandboxing isn't disabled until we can figure out what's wrong.

Yeah, that's the sort of thing I had in mind.

Comment 7

[Haik Aftandilian [:haik]]

Still looking into this, but it appears we have been assuming that, when set, XPCOM_MEM_BLOAT_LOG should contain a filename. I'll work on updating the code to reflect what is described on the BloatView[1] page:

How to run with BloatView
Section

The are two environment variables that can be used.

XPCOM_MEM_BLOAT_LOG

    If set, this causes a bloat log to be printed on program exit, and each time nsTraceRefcnt::DumpStatistics is called. This log contains data on leaks and bloat (a.k.a. usage).

XPCOM_MEM_LEAK_LOG

    This is similar to XPCOM_MEM_BLOAT_LOG, but restricts the log to only show data on leaks.

You can set these environment variables to any of the following values.

    1 - log to stdout.
    2 - log to stderr.
    filename - write log to a file.

1. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/BloatView#How_to_turn_on_refcnt.2Fmemory_logging

Comment 8

[Haik Aftandilian [:haik]]

In ContentParent::AppendSandboxParams(), when XPCOM_MEM_BLOAT_LOG is set to a filename, we determine the parent directory of the file and give content processes write access to that directory. nsMacUtilsImpl::GetDirectoryPath() is used to get the parent directory. nsMacUtilsImpl::GetDirectoryPath() uses nsIFile for its logic for getting the parent directory and resolving symlinks.

When XPCOM_MEM_BLOAT_LOG is set to "1" or "2", nsMacUtilsImpl::GetDirectoryPath() crashes. For the stdout/stderr use of XPCOM_MEM_BLOAT_LOG, we don't need to whitelist anything in the sandbox due to stdout/stderr already being fowarded.

And I see we aren't whitelist anything for XPCOM_MEM_LEAK_LOG which must be a bug.

I'll fix the crash and will whitelist XPCOM_MEM_LEAK_LOG like we do for XPCOM_MEM_LEAK_LOG.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3aa50ee85fa43ea253e43d2d893e523a01ba9e22

Comment 9

[Andrew McCreight [:mccr8]]

Thanks, Haik!

Comment 10

[Haik Aftandilian [:haik]]

Attachment: Bug 1543809 - Can't run with XPCOM_MEM_BLOAT_LOG=1 on OS X r?Alex_Gaynor

Don't assume XPCOM_MEM_BLOAT_LOG is a filename. XPCOM_MEM_BLOAT_LOG and XPCOM_MEM_LEAK_LOG can be set to a filename or "1" or "2" for logging to stdout and stderr respectively.

Set the debug write directory for XPCOM_MEM_LEAK_LOG in the same way we already to for XPCOM_MEM_BLOAT_LOG.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8b2aa73ab267
Can't run with XPCOM_MEM_BLOAT_LOG=1 on OS X r=Alex_Gaynor

Comment 12

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/8b2aa73ab267