public inbox for
 help / color / mirror / Atom feed
From: Jon Turney <>
To: Cygwin Patches <>
Subject: Re: [PATCH] Cygwin: Make 'ulimit -c' control writing a coredump
Date: Wed, 15 Jun 2022 12:40:06 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 15/06/2022 12:21, Jon Turney wrote:
> Factor out pre-formatting a command to be executed on fatal signal, and
> use that for both error_start (if present in the CYGWIN env var) and for
> 'dumper'.
> Factor out executing that command, so we can use it from try_to_debug()
> and when a fatal signal occurs.
> Because we can't control the size of the core dump written by that, only
> invoke dumper if the core file size limit is unlimited.
> Otherwise, if that limit is greater than 0, we will write a .stackdump
> file, as previously.
> Change the default limit from unlimited to 1 MB, to preserve that
> existing behaviour.

Maybe this design tries too hard not to change anything and instead we 

keep default ulimit -c as unlimited

ulimit 0     write nothing
ulimit <=4K  write a .stackdump [*]
ulimit >4K   write a .core

In cases where we wrote something, check afterwards if it's bigger than 
the ulimit and if so, remove it.

(Maybe this still loses if e.g. 1MB of disk space remains, ulimit is 
2MB, actual size of coredump is 3MB, since we'll end up with a partial 
coredump when we shouldn't have written anything, but maybe that's 
what's supposed to happen?)

[*] where 4K is arbitrarily chosen as a bit bigger than any possible 
.stackdump currently.

> Adjust and clarify the associated documentation.
> Also: Fix the (deprecated) cygwin_dumpstack() function so it will now
> write a .stackdump file, even when ulimit -c is zero.
> (Note that cygwin_dumpstack() is still idempotent, which is perhaps odd)
> Also: Fix so that the error_start JIT debugger is now invoked, even when
> ulimit -c is zero.
> Also: Fix uses of console_printf() inside exec_debugger(). It's output
> is written via the Windows console device, so needs to use Windows-style
> line endings.
> Future work: Perhaps we should use the absolute path to dumper, rather
> than assuming it is in PATH, although circumstances in which cygwin1.dll
> can be loaded, but dumper isn't in the PATH are probably rare.
> ---
>   winsup/cygwin/    |   2 +-
>   winsup/cygwin/    |   1 +
>   winsup/cygwin/ | 100 +++++++++++++++++++++++++-----------
>   winsup/cygwin/winsup.h      |   1 +
>   winsup/doc/cygwinenv.xml    |  22 +++++---
>   winsup/doc/utils.xml        |  31 ++++++-----
>   6 files changed, 107 insertions(+), 50 deletions(-)

  reply	other threads:[~2022-06-15 11:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-15 11:21 Jon Turney
2022-06-15 11:40 ` Jon Turney [this message]
2022-06-15 12:30   ` Corinna Vinschen
2022-06-22 13:59     ` Jon Turney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).