[PATCH 1/5] Cygwin: Make 'ulimit -c' control writing a coredump
Corinna Vinschen
corinna-cygwin@cygwin.com
Tue Jan 23 14:29:20 GMT 2024
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
More information about the Cygwin-patches
mailing list