This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
Notes:
- because minidump-analyzer is not a root crate, it doesn't need the
workspace hack.
- allocator-api2 was added in bug 1912019, we don't need to work around
its use in hashbrown anymore.
Differential Revision: https://phabricator.services.mozilla.com/D233788
This is quite an improvement on the quirks of the previous GDI scaling.
It also mostly supports the windows 10+ "Make text bigger" setting: it
reads the value from the registry (albeit at an unofficial location),
but doesn't register a key change listener to update the value if it
changes while the application is open. I think this is very, very likely
to be good enough; I will be surprised if someone notices this
deficiency! The official API is part of UWP and is accessible through
C++ libraries, but not conveniently through win32 APIs, which is why I
use the registry.
Differential Revision: https://phabricator.services.mozilla.com/D221544
Because fallible_collections pulls hashbrown 0.13, we also upgrade
hashlink to 0.8.2, which updates to that version as well. Those were the
last two uses of hashbrown 0.12, so we can update the fake hashbrown
0.12 to 0.13.
We could skip the upgrade of hashlink, but that would leave us with two
fake hashbrowns, and we'd hit https://github.com/rust-lang/cargo/issues/13405
Differential Revision: https://phabricator.services.mozilla.com/D209317
