1. 07 Jan, 2021 1 commit
  2. 11 Jan, 2021 1 commit
  3. 10 Dec, 2020 1 commit
  4. 02 Jun, 2020 1 commit
  5. 05 Jan, 2021 1 commit
  6. 08 Dec, 2020 2 commits
  7. 07 Jan, 2021 1 commit
  8. 06 Jan, 2021 2 commits
  9. 05 Jan, 2021 1 commit
  10. 22 Dec, 2020 1 commit
  11. 07 Dec, 2020 1 commit
  12. 03 Dec, 2020 1 commit
  13. 30 Nov, 2020 1 commit
  14. 12 Nov, 2020 1 commit
  15. 12 Jun, 2020 1 commit
  16. 16 Dec, 2020 1 commit
  17. 04 Jan, 2021 3 commits
  18. 15 Dec, 2020 2 commits
  19. 21 Dec, 2020 2 commits
  20. 14 Aug, 2020 1 commit
  21. 22 Oct, 2020 1 commit
  22. 28 Dec, 2020 1 commit
  23. 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
  24. 04 Jan, 2021 1 commit
  25. 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
  26. 17 Aug, 2020 1 commit
  27. 21 Dec, 2020 1 commit
  28. 18 Dec, 2020 2 commits
  29. 15 Dec, 2020 1 commit
  30. 11 Dec, 2020 1 commit
  31. 10 Dec, 2020 1 commit
  32. 08 Dec, 2020 2 commits