Eric Blake <ebl...@redhat.com> writes:
> On 07/24/2018 01:36 AM, Markus Armbruster wrote:
>> Eric Blake <ebl...@redhat.com> writes:
>>
>>> In kill_qemu() we have an assert that checks that the QEMU process
>>> didn't dump core:
>>> assert(!WCOREDUMP(wstatus));
>>>
>>> Unfortunately the WCOREDUMP macro here means the resulting message
>>> is not very easy to comprehend on at least some systems:
>>>
>
>>> - if (pid == s->qemu_pid && WIFSIGNALED(wstatus)) {
>>> - assert(!WCOREDUMP(wstatus));
>
>>> + } else if (WIFSIGNALED(wstatus)) {
>>> + int sig = WTERMSIG(wstatus);
>>> + const char *signame = strsignal(sig) ?: "unknown ???";
>>> +
>>> + if (!WCOREDUMP(wstatus)) {
>>> + die = false;
>>
>> Does WCOREDUMP(wstatus) depend on the user's ulimit -c?
>
> 'man waitpid' on Linux mentions that WCOREDUMP is nonportable, but
> does not mention any interaction with setrlimit. But a quick test
> shows:
>
> $ ulimit -S -c 0
> $ cat foo.c
> int main(int argc, char **argv) {
> return *argv[1];
> }
> $ gcc -o foo -Wall foo.c
> $ ./foo 1
> $ ./foo
> Segmentation fault (core dumped)
> $
>
> the output was produced by bash, which uses waitpid() - and therefore
> the fact that bash reports the core dump even when no core file is
> created is promising.
Proof beats plausibility argument:
$ cat wcordump.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
int
main(void)
{
pid_t child = fork();
int wstatus;
if (child < 0) {
perror("fork");
exit(1);
}
if (!child) {
abort();
}
if (waitpid(child, &wstatus, 0) < 0) {
perror("waitpid");
exit(1);
}
if (WIFSIGNALED(wstatus)) {
printf("sig %d %d\n",
WTERMSIG(wstatus), WCOREDUMP(wstatus));
} else {
printf("no sig\n");
}
exit(0);
}
$ gcc -Wall -g -O wcordump.c
$ (ulimit -c unlimited; ./a.out)
sig 6 128
$ (ulimit -c 0; ./a.out)
sig 6 0
Looks like WCOREDUMP() does depend on my ulimit -c.
