1749249 - Diagnostics in child processes don't present (Windows)

Status: UNCONFIRMED

(Core :: Security: Process Sandboxing, defect, P3)

Description

[Steve Williams]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Tried dump() from javascript on a content process.

Actual results:

Nothing in stdout/err

Expected results:

Diagnostics should have presented to stdout/err

Comment 1

[Steve Williams]

Windows only bug, similar in nature to this legacy report : https://bugzilla.mozilla.org/show_bug.cgi?id=875210

That will resolve this Windows only bug robustly and provide superior reporting functionality such as filters and custom presentation (color coding, screen overlay, redirect to page console, whatever).

Broken content process as of ESR 91.4 & later. Issue has been present for quite some time, so affects all recent versions of FF.

Robust fix is to route diagnostics over IPC bridge to parent process which can log as normal - all platforms.

Propose new IPC message :

MSG_DIAGNOSTICS [string, ERROR|WARN|INFO, FLAGS]

... then do whatever with it in root, which amounts to a printf for warn & info & a fprintf(stderr for errors for default implementation.

Interim temporary on Windows, which doesn't hurt to be there permanently is to OutputDebugString which will show up in Visual Studio Debug window under debugger. That's insufficient for complete fix as release builds don't see that but allows developers to get debug output immediately.

https://searchfox.org/mozilla-central/source//js/xpconnect/src/Sandbox.cpp#151

#ifdef XP_WIN
if (IsDebuggerPresent())
OutputDebugStringA(cstr);
#endif

... just under the android & mac/os specifics in SandboxDump

So suggest that is inserted, then go the whole way & also route diagnostics to root process - that work being platform independent.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Content Processes' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Steve Williams]

Windows only bug, similar in nature to this legacy report : https://bugzilla.mozilla.org/show_bug.cgi?id=875210

Robust fix is to route diagnostics over IPC bridge to parent process which can log as normal - all platforms.

via proposed new IPC message : MSG_DIAGNOSTICS [string, ERROR|WARN|INFO, FLAGS]

... then do whatever with it in root, which amounts to a printf for warn & info & a fprintf(stderr for errors for default implementation.

Interim temporary on Windows, which doesn't hurt to be there permanently is to OutputDebugString which will show up in Visual Studio Debug window under debugger. That's insufficient for complete fix as release builds don't see that but allows developers to get debug output immediately.

https://searchfox.org/mozilla-central/source//js/xpconnect/src/Sandbox.cpp#151

#ifdef XP_WIN
if (IsDebuggerPresent())
OutputDebugStringA(cstr);
#endif

... just under the android & mac/os specifics in SandboxDump

So suggest that is inserted, then go the whole way & also route diagnostics to root process - that work being platform independent.

Comment 4

[Simona Badau, Desktop QA]

Moving this to Core -> IPC so our developers can take a look at this - if this is not the right component, please move it to a more appropriate one.
Thanks!

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Moving to sandboxing, as this is being blocked by our process sandbox.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Robust fix is to route diagnostics over IPC bridge to parent process which can log as normal - all platforms.

This is bug 1345046.

Comment 7

[Steve Williams]

The following resolves :

#include <windows.h>
#include <iostream>

// Compile to console_test.exe
// Start with no command line arguments to invoke parent, which invokes child.
// Observe diagnostics to console delivered from both processes.

int main(int argc, char* argv[])
{
bool is_child = (argc >= 2) && !strcmp(argv[1], "-child");

if (is_child)
{
     std::cout << std::endl << "<><> child process !" << std::endl;
}
else
{
   PROCESS_INFORMATION pi;
   ZeroMemory(&pi, sizeof(pi));

   STARTUPINFO si;
   ZeroMemory(&si, sizeof(si));
   si.cb = sizeof(si);
   si.dwFlags = STARTF_USESTDHANDLES;

   si.hStdOutput = ::GetStdHandle(STD_OUTPUT_HANDLE);
   si.hStdError  = ::GetStdHandle(STD_ERROR_HANDLE);

   TCHAR szCommandLine[] = TEXT("console_test.exe -child");

   if (!::CreateProcess(NULL, szCommandLine, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi))
   {
       std::cout << "CreateProcess failed with error " << GetLastError() << std::endl;
       return 1;
   }

   std::cout << std::endl << "<><> parent process !" << std::endl;

   ::CloseHandle(pi.hProcess);
   ::CloseHandle(pi.hThread);
}

return 0;

}

Comment 8

[Steve Williams]

Just removed

si.dwFlags = STARTF_USESTDHANDLES;
si.hStdOutput = ::GetStdHandle(STD_OUTPUT_HANDLE);
si.hStdError  = ::GetStdHandle(STD_ERROR_HANDLE);

from above & it still prints from child process. So something more subtle going on in gecko. Perhaps an issue of a Windows app opening a console rather than a straight console app.