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