Open Bug 1189223 Opened 9 years ago Updated 1 year ago

[e10s] stderr from sandboxed child process is not output into the terminal on Windows

Categories

(Core :: Security: Process Sandboxing, defect)

All
Windows
defect

Tracking

()

Tracking Status
e10s - ---
firefox42 --- affected

People

(Reporter: bobowen, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: sb+)

+++ This bug was initially created as a clone of Bug #1171796 +++

Follow-up to bug 1171796 for the console logging issue.

Standard logging to the console is not working for the child process with the sandbox turned on.

If you redirect output to a file it does work.
I think this is a less serious problem than the NSPR logging one as you can work around this by simply redirecting output to a file, which I personally find much more useful anyway.
For example when using mozilla-build:
./mach run &> console.out

However, we should probably track with one of the e10s categories.
tracking-e10s: --- → ?
Priority: -- → P1
Whiteboard: sb?
When the logging tries to do the fprintf we get an ERROR_INVALID_HANDLE.

I'm pretty sure this is the same thing causing the problem in bug 1247959.

Looks like they have same issue with the sandbox on chromium:

https://chromium.googlesource.com/chromium/src/+/79dc59ac7602413181079ecb463873e29a1d7d0a/content/common/sandbox_win.cc#745
See Also: → 1247959
known work around using file output.
Whiteboard: sb? → sb+
Blocks: sb-log
Priority: P1 → --
See Also: → 1648850
Severity: normal → S3

This limitation becomes an issue when using the new JavaScript tracing feature (bug 1803616),
which logs javascript traces to stdout from content processes.

A workaround exists mentioned in bug 1257155, is to run firefox like this from powershell:
.\firefox.exe | Tee-Object CON

This prevents having to completely disable sandboxing via set MOZ_DISABLE_CONTENT_SANDBOX=1.

You need to log in before you can comment on or make changes to this bug.