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...
prev parent 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).