On Tue, 6 Aug 2024 11:27:40 +0200 Laurent Vivier <lvivier(a)redhat.com> wrote:On 06/08/2024 02:27, David Gibson wrote:This: isolation.c:374: prctl(PR_SET_DUMPABLE, 0);On Mon, Aug 05, 2024 at 04:10:27PM +0200, Laurent Vivier wrote:I don't know what, but there is something that prevent passts to generate a core dump (I tried abort(), (char *)0 = 0, it works with a simple program, not with passt).We use our own implementation of assert() because the glic implementation uses syscalls that aren't in our seccomp filter, see 7a8ed9459dfe ("Make assertions actually useful"). And we replaced it by an err(), followed by an abort() (that is also catched by seccomp).I think Stefano's said everything I would on the change itself, but..We don't have a coredump or a backtrace but we have at least the error message... only if logging is enabled.Whether we get a coredump shouldn't be affected by our weird ASSERT() here. If coredumps are enabled (which they're not by default on current distros, AFAICT), we should still get a coredump with the SIGSYS here, just as we would for a SIGABRT.Moreover, if we use gdb it doesn't stop on the syscall but exit and we cannot locate the exit point. And as strace doesn't report the syscall that generates the SIGSYS, it makes hard to find which one it is.This is probably caused by the seccomp filter instead. You could skip applying that by commenting this out: if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) || prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)) die_perror("Failed to apply seccomp filter"); and find out which system call causes that... maybe we could add it to the 'make valgrind' target, then, or add a 'make debug' one. It's just important to clearly show that users should *not* use any such target for regular operation. -- Stefano