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.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
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 includes some small fixes to desktop Suggest code and tests due to changes
in the `suggest` app-services component. It also incorporates D243740 by
@daisuke since it's required for vendoring.
This vendor replaces exposure suggestions with dynamic suggestions in the
`suggest` component, which breaks a few desktop tests. I disabled them for now
and will address them in bug 1961040.
Depends on D244233
Differential Revision: https://phabricator.services.mozilla.com/D245826
Do this by upgrading `application-services` repos to a commit that
_only_ differs from the current one in its `rusqlite` dependency.
Differential Revision: https://phabricator.services.mozilla.com/D244233
The issue was that the `default-hasher` feature wasn't turned on, which
made it so the build hack that substitutes older hashbrown versions with
v0.15.2 was failing.
Differential Revision: https://phabricator.services.mozilla.com/D244942
Replaced `ScaffoldingConverter` with a set of `FfiValue*` classes. The
differences are:
* The new classes better match other `uniffi-bindgen-gecko-js` names,
and also use familiar UniFFI terms like `Lift` and `Lower`.
* Object handles are now freed if there's an error.
* The new classes store the FFI value internal rather than defining an
`IntermediateType` associated type.
* Moved header files into `mozilla/uniffi/` and removed the `UniFFI`
prefix from the filename. This avoids weird filenames like
`UniFFIFfiValue.h`
Differential Revision: https://phabricator.services.mozilla.com/D240696
Replaced `ScaffoldingConverter` with a set of `FfiValue*` classes. The
differences are:
* The new classes better match other `uniffi-bindgen-gecko-js` names,
and also use familiar UniFFI terms like `Lift` and `Lower`.
* Object handles are now freed if there's an error.
* The new classes store the FFI value internal rather than defining an
`IntermediateType` associated type.
* Moved header files into `mozilla/uniffi/` and removed the `UniFFI`
prefix from the filename. This avoids weird filenames like
`UniFFIFfiValue.h`
Differential Revision: https://phabricator.services.mozilla.com/D240696
Split out, because the upgrades are split into multiple commits, but we
require a single vendoring to avoid duplicated packages.
Differential Revision: https://phabricator.services.mozilla.com/D241959
Notable WebGPU CTS changes:
- Demotions from tier 2 to tier 3:
- `webgpu:shader,execution,expression,unary,{i32,u32}_conversion:f32:*` started regressing on Windows.
- Promotions to tier 2 from tier 3:
- Across all platforms:
- `webgpu:shader,execution,expression,call,builtin,cross:f32:*`
- `webgpu:shader,execution,expression,unary,i32_conversion:abstract_float:*`
- `webgpu:shader,execution,expression,unary,u32_conversion:abstract_float:*`
- `webgpu:shader,execution,limits:nesting_depth_braces:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_copy:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_elementwise:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_mixed:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:scalar_zero_value:*` was promoted on Linux and Windows, but stays in macOS on account of failing `f16` functionality. My guess is that these failures are also present on the other platforms, but we don't see the because `shader-f16` is not aviailable on our other CI platforms yet.
- From macOS, completing the set of all platforms passing:
- `f16` functionality, which, again, was likely not visible on our other CI platforms before:
- `webgpu:shader,execution,expression,call,builtin,cross:f16:*`
- `webgpu:shader,validation,decl,override:type:*`
- `webgpu:api,validation,capability_checks,limits,maxUniformBufferBindingSize:createBindGroup,at_over:*`
was promoted on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D243593
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.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
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
