Can't run with XPCOM_MEM_BLOAT_LOG=1 on OS X

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
normal
RESOLVED FIXED
2 months ago
2 months ago

People

(Reporter: mccr8, Assigned: haik)

Tracking

(Blocks 1 bug)

unspecified
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(1 attachment)

Reporter

Description

2 months ago

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.

Reporter

Comment 1

2 months ago

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

Reporter

Comment 2

2 months ago

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

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → WONTFIX

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

Flags: needinfo?(continuation)
Reporter

Comment 4

2 months ago

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

Flags: needinfo?(continuation)

Comment 5

2 months ago

(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.

(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.

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee

Updated

2 months ago
Assignee: nobody → haftandilian
Priority: -- → P1
Assignee

Comment 7

2 months ago

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
Assignee

Comment 8

2 months ago

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

Reporter

Comment 9

2 months ago

Thanks, Haik!

Assignee

Comment 10

2 months ago

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

2 months ago
Pushed by haftandilian@mozilla.com:
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

2 months ago
bugherder
Status: REOPENED → RESOLVED
Closed: 2 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.