[PATCH] Cygwin: Make 'ulimit -c' control writing a coredump

Jon Turney jon.turney@dronecode.org.uk
Wed Jun 22 13:59:14 GMT 2022

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

More information about the Cygwin-patches mailing list