public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Jon Turney <jon.turney@dronecode.org.uk>
To: Cygwin Patches <cygwin-patches@cygwin.com>
Subject: Re: [PATCH] Cygwin: Make 'ulimit -c' control writing a coredump
Date: Wed, 22 Jun 2022 14:59:14 +0100	[thread overview]
Message-ID: <148dc994-81e2-b214-800d-4aaca15038fd@dronecode.org.uk> (raw)
In-Reply-To: <YqnQzVMifY8j+aK8@calimero.vinschen.de>

On 15/06/2022 13:30, Corinna Vinschen wrote:
> On Jun 15 12:40, Jon Turney wrote:
>> 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
>> should:
>>
>> keep default ulimit -c as unlimited
>>
>> ulimit 0     write nothing
>> ulimit <=4K  write a .stackdump [*]
>> ulimit >4K   write a .core
> 
> Sounds good.

Thinking this over, that probably limits the ability to improve 
.stackdump  files in any way (i.e. adding a map of loaded modules and 
addresses would make it possible to realisticly interpret it when IP 
isn't in the executable or cygwin DLL (which have fixed addresses)).

Since the minimum realistic coredump file size is much larger than that 
(a coredump for hello_world.c is about 2MB), the cut-off could be set 
higher e.g. 0.5MB.

Or maybe there needs to be some more explicit configuration of which 
format is wanted?

>> 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?)
> 
> If disk space is low, shit happens.

Yeah, but I was kind of assuming something definite happens. :)

Researching this further the linux manpage for setrlimit() says that 
dumps are truncated to the limit, but the glib manual says that if the 
core file would be larger than the limit, no core file is created, so 
maybe the behaviour in that case isn't fully specified...

      reply	other threads:[~2022-06-22 13:59 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
2022-06-15 12:30   ` Corinna Vinschen
2022-06-22 13:59     ` Jon Turney [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=148dc994-81e2-b214-800d-4aaca15038fd@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).