Bugzilla

The failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` look like instances where the child process was just about to be done with shutdown when we triggered the crash. But because we triggered the crash, the remote thread that we created started running `google_breakpad::ExceptionHandler::HandleException`, and it is thus now holding `ExceptionHandler::handler_stack_critical_section_`. So, while the exception handler was preparing for crashing, the main thread reached `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` and got stuck there, because it cannot acquire `ExceptionHandler::handler_stack_critical_section_`. So, I would say that seeing failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` are false positives that suggest that we may be a bit too strict on the amount of time that we are giving to child processes.

The failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` look like instances where the child process was just about to be done with shutdown when we triggered the crash. But because we triggered the crash, the remote thread that we created started running `google_breakpad::ExceptionHandler::HandleException`, and this thread is thus now holding `ExceptionHandler::handler_stack_critical_section_`. Then, while the exception handler was preparing for crashing in the remote thread, the main thread reached `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` and got stuck there, because it cannot acquire `ExceptionHandler::handler_stack_critical_section_`. So, I would say that seeing failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` are false positives that suggest that we may be a bit too strict on the amount of time that we are giving to child processes.

The failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` look like instances where the child process was just about to be done with shutdown when we triggered the crash. But because we wanted to trigger a crash, the remote thread that we created started running `google_breakpad::ExceptionHandler::HandleException`, and this thread is thus now holding `ExceptionHandler::handler_stack_critical_section_`. Then, while the exception handler was preparing for crashing in the remote thread, the main thread reached `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` and got stuck there, because it cannot acquire `ExceptionHandler::handler_stack_critical_section_`. So, I would say that seeing failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` are false positives that suggest that we may be a bit too strict on the amount of time that we are giving to child processes.

The failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` look like instances where the child process was just about to be done with shutdown when we triggered the crash. But because we wanted to trigger a crash, the remote thread that we created started running `google_breakpad::ExceptionHandler::HandleException`, so this thread is thus now holding `ExceptionHandler::handler_stack_critical_section_`. Then, while the exception handler was preparing for crashing in the remote thread, the main thread reached `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` and got stuck there, because it cannot acquire `ExceptionHandler::handler_stack_critical_section_`. So, I would say that seeing failures in `xul.dll!CrashReporter::UnsetRemoteExceptionHandler` are false positives that suggest that we may be a bit too strict on the amount of time that we are giving to child processes.