Re: pkg/59808 (random python3 process crashes in NetBSD VMs)

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR pkg/59808; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: twaldmann%thinkmo.de@localhost
Cc: gnats-bugs%netbsd.org@localhost, port-amd64-maintainer%netbsd.org@localhost,
	pkgsrc-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, twaldmann%thinkmo.de@localhost
Subject: Re: pkg/59808 (random python3 process crashes in NetBSD VMs)
Date: Sun, 30 Nov 2025 20:45:48 +0000

 > Date: Sun, 30 Nov 2025 16:59:09 +0100
 > From: twaldmann%thinkmo.de@localhost
 >=20
 > > Is there any output you can share?  Is there a core dump?
 >=20
 > Currently I don't have anything more. It's hard to debug on the github=20
 > runners, but I can also run a netbsd vagrant virtualbox VM locally and=20
 > reproduce if you like.
 >=20
 > I am not really familiar with NetBSD. I just want to make sure that=20
 > borgbackup runs well on this platform, but I am no (real) user myself.
 >=20
 > So, can you tell me what to look for, how and where?
 
 I think the next diagnostics are likely to be more about the
 borgbackup or tox test harness than about NetBSD, and how they handle
 a process crashing generally.
 
 - Is there stdout/stderr stored anywhere?
 
 - Did the parent process determine it terminated on a signal, and if
   so, what signal, and did it dump core?
 
   (These are standard Unix questions answered by the wait family of
   system calls and associated predicates WIFSIGNALED, WTERMSIG,
   WCOREDUMP -- nothing different about NetBSD.)
 
 - Can you find a core dump?
 
   By default, it will be called %n.core where %n is the program name,
   and it will appear in the process's working directory -- unless it's
   run from a set-user-id or set-group-id executable, in which case a
   core dump will go in /var/crash but only if you set the sysctl knob
   kern.coredump.setid.dump=3D1.
 
   (See `sysctl kern.defcorename' and `sysctl kern.coredump' for all
   the parameters.  Enable setid core dumps with `sysctl -w
   kern.coredump.setid.dump=3D1', though I doubt you're using any setid
   processes.  More information:
   https://man.NetBSD.org/NetBSD-10.1/core.5,
   https://man.NetBSD.org/NetBSD-10.1/sysctl.7)
 
   If you can find a core dump, and it's (say) from a program called
   /usr/pkg/bin/foo, can you get a stack trace out of gdb?
 
   # gdb /usr/pkg/bin/foo /path/to/foo.core
   (gdb) bt
   (gdb) info registers
   (gdb) frame apply all info locals
 
 - If it terminated on a signal but there's no core dump: Are you
   running with any resource limits (getrlimit/setrlimit, or the shell
   ulimit builtin -- all standard POSIX) that prevent core dumps, or
   are you running a set-user-id or set-group-id executable?
 
 - Is there any relevant output in `dmesg'?  It might say whether a
   core was dumped, in case the parent process ignores that
   information.
 
 I ran the test suite three times in a VM by loosely following the
 instructions at
 https://github.com/borgbackup/borg/blob/9a0122995c32aa657a2b1cac7a015cec6d1=
 a89ab/.github/workflows/ci.yml#L432-L468
 but so far I haven't seen any crashes.  Takes about an hour to run;
 how often do the crashes occur?