Suspending the target process threads is currently an all-or-nothing operation that prevents minidump generation upon failure. The system we currently use is to iterate over the threads we've enumerated during initialization. This is an inherently racy operation as new threads can be created in the meantime and existing ones can quit. This is partially handled in that we tolerate being unable to suspend certain threads assuming that we stop at least a single one.

There should be ways to improve this but they're not clear-cut and probably needs some experimentation. One possibility is to send a SIGSTOP signal to the target process and wait for it to settle down before ptrace()-ing it. SIGSTOP is a big hammer that needs to be used with caution so I don't know what kind of issues we might encounter, but it could make the process more reliable by getting rid of some races (or at least leaving the kernel to handle them).

Additionally we might consider dumping threads we couldn't suspend. The data we'll get might be garbage but I don't really mind, we get garbage all the time in crash reports, it could also be useful. Let's say it would certainly be better than nothing. The reason why we never tried to do it with Breakpad is simple enough: handling errors is a chore! But here it's a lot easier. We could factorize the code for writing a single thread in thread_list_stream::write() and ignore individual failures (or even better, record them!).