Mark, we are seeing issues before we try and get symbols and symbolize stack traces with minidumps not being present, or more minidumps than we expect.  

See  crbug.com/671049  for a case where we can't find them on macs.  

Can you talk a little more to how dumps get written to the crashpad_database_util and the steps before we query it for the current dumps?  We are wondering if our running in isolation isn't working correctly or if we are cutting off processing too soon for the dumps to be generated.  

crashpad_handler writes the dumps to the Crashpad database in the “pending” state before letting the crashy program go on its way and finish crashing in a way that’s visible to the rest of the system, such as to its parent process via waitpid(). Subsequently, another thread in crashpad_handler is supposed to pick up the pending crash and decide what to do with it, which basically means that it’ll either try to upload it or not. At some point, the report will transition from “pending” to “completed”. That means that no more upload attempts will be made. This either happens quickly the first time that the pending report is examined (because uploads are off), or it can happen because the upload succeeds, or it can happen because the upload fails but won’t be retried. Even when it happens quickly, though, it’s a bit racy with any action that you might take as soon as the crash becomes visible to the rest of the system.

If you’re the parent of a test, and the test crashes, and you learn of the crash when you call waitpid(), and you immediately take action to run crashpad_database_util to find the crash, then you should be aware that this action can race crashpad_handler transitioning the report from “pending” to “completed.”

If you’re only asking crashpad_database_util to tell you about completed reports, then you won’t find it in the list if crashpad_handler hasn’t had a chance to move it to completed yet.

That’s probably what would cause reports to not show up. As for more reports than expected, you should bear in mind that Crashpad is watching more than just your main test process, it’s potentially watching all of that process’ children as well, and if any of them crash, nobody’s necessarily going to tell you about it (the crash would be reported to the parent process, the main test process, via waitpid()), but Crashpad will produce a report anyway. If you run multiple test processes in parallel as your own children and they share the same database, that’ll be another way that multiple processes can (roughly) simultaneously wind up producing reports in the same database.