Skip to content
GitLab
Switch branch/tag
  1. 07 Jan, 2021 1 commit
  3. 11 Jan, 2021 1 commit
  5. 10 Dec, 2020 1 commit
  7. 02 Jun, 2020 1 commit
  9. 05 Jan, 2021 1 commit
  11. 08 Dec, 2020 2 commits
  13. 07 Jan, 2021 1 commit
  15. 06 Jan, 2021 2 commits
  17. 05 Jan, 2021 1 commit
  19. 22 Dec, 2020 1 commit
  21. 07 Dec, 2020 1 commit
  23. 03 Dec, 2020 1 commit
  25. 30 Nov, 2020 1 commit
  27. 12 Nov, 2020 1 commit
  29. 12 Jun, 2020 1 commit
  31. 16 Dec, 2020 1 commit
  33. 04 Jan, 2021 3 commits
  35. 15 Dec, 2020 2 commits
  37. 21 Dec, 2020 2 commits
  39. 14 Aug, 2020 1 commit
  41. 22 Oct, 2020 1 commit
  43. 28 Dec, 2020 1 commit
  45. 01 Dec, 2020 1 commit
    • Gabriele Svelto's avatar
      Bug 1624467 - Fix a race in child process crash generation which could lead to... · ba374559
      Gabriele Svelto authored 
      Bug 1624467 - Fix a race in child process crash generation which could lead to a full browser crash. r=KrisWright, a=RyanVM

In bug 1614933 we discovered a potential deadlock in Windows-specific code
could cause the main process to get stuck waiting for a child process to send
out its annotations after it crashed. As it turns out this flaw was also
present in the Linux and macOS versions but was not visible because on those
platforms we used non-blocking writes when writing out annotations and we
didn't check if they were actually written out (see bug 1666383). Since the
child process would not stop it couldn't possible deadlock. However, the
relevant code is still racy: if the child process' pipe would start rejecting
writes early, the child process could race past the main process leading to
the crash. The sequence of events in the racy case would be the following:

- We hit an exception in the child process, we enter the exception handler and
  signal the main process to write a minidump
- The crash generation thread in the main process is woken up, writes the
  minidump then signals the child process it can continue
- The child process writes out the crash annotations then exits
- At this stage the crash generation thread in the main process should have
  picked up the annotations and stored the crash report in the pid-to-minidump
  table. But let's assume the scheduler doesn't wake up this thread for now.
- The main thread in the main process wakes up in response to the child
  process shutdown, it will try to grab the minidump
- The minidump is not available yet because the crash generation client thread
  hasn't run yet and there's nothing preventing the main thread to race past it:
  the main process crashes trying to access a NULL pointer

To this issue the act of transfering the exception-time annotations is decoupled
from the act of writing the minidump in both the main process and the child
process. This way when the child process is forced to wait for the main process
to act on the minidump before the crash annotations are written out, and by the
time the child process quits the main process has reliably acquired the lock to
the pid-to-minidump table so that the race can't happen anymore.

Note: to implement the second change the child process exception handler
should execute the minidump callback after it has request the creation of a
minidump. For some reason this was implemented in breakpad only for the
in-process crash case, not the out-of-process one. I modified the relevant
code in the exception handler to invoke the callback in both cases.

Differential Revision: https://phabricator.services.mozilla.com/D97964
      ba374559
  47. 04 Jan, 2021 1 commit
  49. 16 Dec, 2020 1 commit
    • Toshihito Kikuchi's avatar
      Bug 1644240 - Suppress playing a sound if Diebold Warsaw's modules are... · d26b9fc2
      Toshihito Kikuchi authored 
      Bug 1644240 - Suppress playing a sound if Diebold Warsaw's modules are partially unloaded. r=cmartin, a=RyanVM

This patch is to mitigate the crash which was probably caused by Diebold Warsaw.
We couldn't reproduce the problem, but our crash reports indicate the crash happened
when `winmm!mciwindow` called `USER32!GetMessageA` but it was redirected to a freed
buffer.  This happens Firefox calls to `PlaySound` e.g. showing the menu bar by
pressing Alt key, or showing a dialogbox.

Most of (not 100%) the crash instances have wslbdhm64 loaded but wslbscrwh64.dll
was unloaded.  The proposed mitigation is to suppress playing a sound under
such a condition.

Differential Revision: https://phabricator.services.mozilla.com/D99705
      d26b9fc2
  51. 17 Aug, 2020 1 commit
  53. 21 Dec, 2020 1 commit
  55. 18 Dec, 2020 2 commits
  57. 15 Dec, 2020 1 commit
  59. 11 Dec, 2020 1 commit
  61. 10 Dec, 2020 1 commit
  63. 08 Dec, 2020 2 commits