1563568 - Parent process not generating minidump in opt mac xpcshell test

Status: RESOLVED INVALID

(Toolkit :: Crash Reporting, defect)

Description

[Bobby Holley (:bholley)]

I've got some code that causes intermittent crashes in opt mac xpcshell tests only. The only crash dumps I get are from the child processes (which crash after the parent process crashes), which isn't all that useful.

I added some logging in the exception handler, here's the control flow:

(1) We get a message in ExceptionHandler::WaitForMessage: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/handler/exception_handler.cc#501

(2) We take the else branch: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/handler/exception_handler.cc#559

(3) We invoke WriteMinidumpWithException: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/handler/exception_handler.cc#580

(4) We call RequestDumpForException: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/handler/exception_handler.cc#382

(5) We send a message, which succeeds: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/crash_generation/crash_generation_client.cc#77

(6) We hit the exit_after_write case, which calls exit: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/handler/exception_handler.cc#388

(7) The listener loop receives another message, and hits the |return NULL| case: https://searchfox.org/mozilla-central/rev/11712bd3ce7454923e5931fa92eaf9c01ef35a0a/toolkit/crashreporter/breakpad-client/mac/handler/exception_handler.cc#517

So somewhere in there is presumably unexpected behavior. Guidance?

Comment 1

[Gabriele Svelto [:gsvelto]]

This smells like a race in the main process message handler. I guess that the content process crash message arrives at a bad time during the handling of the main process crash. I'll investigate it today.

Comment 2

[Gabriele Svelto [:gsvelto]]

It seems to me that (4) is happening while we're writing the minidump for the main process. That seems to be the request coming from the crashed child process. What follows if I'm following correctly is that we drop writing the original minidump and switch to the writing the one for the content process. Once that's done we quite leaving no minidump for the main process. If my interpretation is correct - and I need to double- and probably triple-check it - we should be able to fix it by preventing breakpad from taking more minidumps once in-process minidump generation starts.

Comment 3

[Bobby Holley (:bholley)]

I realized after some extensive debugging that the PID markers in xpcshell test logs lie, and content output is attributed to the parent pid. So this was actually a crash in the content process, and being handled correctly. Sorry for the noise.