Re: [PATCH 1/5] Cygwin: Make 'ulimit -c' control writing a coredump

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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