If we are running a background thread in the launcher process to log failures,
then allowing the main thread to proceed with monkeypatching system calls is a
Bad Idea. This patch gives us an environment variable that, when set, indicates
that it is unsafe for PoisonIOInterposer to run.
This scenario is an uncommon one, but one that we must account for nonetheless.
Differential Revision: https://phabricator.services.mozilla.com/D21607
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D19697
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
***
Format cleanup
Differential Revision: https://phabricator.services.mozilla.com/D19697
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
