On Jan 23 14:20, Jon Turney wrote: > On 12/01/2024 14:09, Jon Turney wrote: > > Pre-format a command to be executed on a fatal error to run 'dumper' > > (using an absolute path). > > > > Factor out executing a pre-formatted command, so we can use that for > > invoking the JIT debugger in try_to_debug() (if error_start is present > > in the CYGWIN env var) and to invoke dumper when a fatal error occurs. > > > > So, there is a small problem with this change: because dumper itself > terminates the dumped process, it doesn't go on to exit with the signal+128 > exit status. > > (In fact, it seems to exit with status 0 when terminated by an attached > debugger terminating, which isn't great) > > That's relatively easy to fix: just use the '-n' option to dumper so it > detaches before exiting, to prevent that terminating the dumped process, but > then we run into the difficulties of reliably detecting that dumper has > attached and done it's work, so it's safe for us to exit. > > Attached patch does that, and documents the expectations on the error_start > command a bit more clearly.
Please push. > Even then this is clearly not totally bullet-proof. Maybe the right thing to > do is add a suitable timeout here, so even if we fail to notice the > DebugActiveProcess() (or there's a custom JIT debugger which just writes the > fact a process crashed to a logfile or something), we'll exit eventually? Timeouts are just that tiny little bit more bullet-proof, they still aren't totally bullet-proof. What timeout were you thinking of? milliseconds? Corinna
