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

> Date: Sun, 30 Nov 2025 16:59:09 +0100
> From: [email protected]
> 
> > Is there any output you can share?  Is there a core dump?
> 
> Currently I don't have anything more. It's hard to debug on the github 
> runners, but I can also run a netbsd vagrant virtualbox VM locally and 
> reproduce if you like.
> 
> I am not really familiar with NetBSD. I just want to make sure that 
> borgbackup runs well on this platform, but I am no (real) user myself.
> 
> 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=1.

  (See `sysctl kern.defcorename' and `sysctl kern.coredump' for all
  the parameters.  Enable setid core dumps with `sysctl -w
  kern.coredump.setid.dump=1', 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/9a0122995c32aa657a2b1cac7a015cec6d1a89ab/.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?