| 4 Jan 2026 |
 Randy Eckenrode | Is exit status 139 a segmentation fault? What could be causing man to crash? | 15:37:56 |
| Randy Eckenrode | Can we get console logs from Hydra? That might have a stack trace. | 15:38:13 |
| Randy Eckenrode | * (Just Googled it.) Is exit status 139 a segmentation fault? What could be causing man to crash? | 15:39:05 |
 vcunat | I'll log in and see what I can get. | 16:15:32 |
| vcunat | The man's log file doesn't seem helpful:
System information (uname -a): Darwin 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:55 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T8103 arm64 arm
.. contents:: :depth: 2
FAIL: man1/manconv.1
====================
man -E UTF-8 -l ./man1/manconv.1 failed with exit status 139 and error output:
FAIL man1/manconv.1 (exit status: 139)
FAIL: man1/whatis.1
===================
man -E UTF-8 -l ./man1/whatis.1 failed with exit status 139 and error output:
FAIL man1/whatis.1 (exit status: 139)
FAIL: man5/manpath.5
====================
man -E UTF-8 -l ./man5/manpath.5 failed with exit status 139 and error output:
FAIL man5/manpath.5 (exit status: 139)
| 16:23:50 |
| vcunat | No code-signing logs, if I'm holding it right. | 16:26:22 |
| Randy Eckenrode | I don’t think this is code-signing. I think this is a plain crash. But why? Is the build directory still there? | 16:29:44 |
| Randy Eckenrode | Does running the command manually crash? | 16:29:55 |
|  Moraxyc changed their profile picture. | 16:41:17 |
| Moraxyc changed their profile picture. | 16:43:27 |
| vcunat | 🤔 the /nix/store path doesn't seem to have remained after --keep-failed build. | 16:43:37 |
| vcunat | And the file from the temporary directory is looking for libmandb-*.dylib on that path. | 16:44:26 |
| Randy Eckenrode | src/man is a script. It tries to set up DYLD_LIBRARY_PATH to point to the dylibs in the build. Is something not right with that? | 16:54:58 |
| Randy Eckenrode | This is what it looks like for me after I run checkPhase to generate it.
# Add our own library path to DYLD_LIBRARY_PATH
DYLD_LIBRARY_PATH="/var/folders/yf/1c0ncp6s14n1sb_87_640lsm0000gn/T/nix-shell.zQPn4f/man-db-2.13.1/libdb/.libs:/var/folders/yf/1c0ncp6s14n1sb_87_640lsm0000gn/T/nix-shell.zQPn4f/man-db-2.13.1/lib/.libs:$DYLD_LIBRARY_PATH"
# Some systems cannot cope with colon-terminated DYLD_LIBRARY_PATH
# The second colon is a workaround for a bug in BeOS R4 sed
DYLD_LIBRARY_PATH=`$ECHO "$DYLD_LIBRARY_PATH" | /nix/store/4s0iv69d8m17v0bz3y5vry5byr3ml8vb-gnused-4.9/bin/sed 's/::*$//'`
export DYLD_LIBRARY_PATH
if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
# Run the actual program with our arguments.
func_exec_program ${1+"$@"}
fi
| 16:55:42 |
| vcunat | Ah, src/man | 16:57:04 |
| vcunat | I was running the unwrapped binary. | 16:57:12 |
| vcunat | Had to set DYLD manually. | 16:57:17 |
| vcunat | But then it's failing to find the config file. | 16:57:29 |
| vcunat | And if I specify that, it's failing to find executables (nroff) | 16:57:46 |
| vcunat | 🤔
src/man -C ./src/man_db.conf ./man/man5/manpath.5
man: command exited with status 255: /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/libexec/man-db/zsoelim | /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t ANSI_X3.4-1968//IGNORE | tbl | nroff -mandoc -rLL=222n -rLT=222n -Tascii
| 16:58:50 |
| vcunat | * And if I specify that, it's failing to find executables (nroff) EDIT: ah no, executables get found by the wrapped one. | 16:59:40 |
| vcunat | That doesn't look like the same error, though. | 17:00:00 |
| vcunat | Also, the machine did manage to succeed the whole build once during my debugging 😅 | 17:00:42 |
| vcunat | Could it be this log line?
XprotectService: [com.apple.xprotect:xprotect] File /nix/var/nix/builds/nix-46977-2307007369/man-db-2.13.1/src/.libs/whatis failed on loadCmd /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/lib/man-db/libmandb-2.13.1.dylib (loadCmd resolved to: (path not found), bundleURL: (null))
| 17:12:55 |
| Randy Eckenrode | That seems like DYLD_LIBRARY_PATH isn’t working. | 17:14:40 |
| vcunat | At the very least it looks like the build system is trying to run some executables incorrectly wrapped. | 17:14:48 |
| vcunat | I see a few others like that. | 17:14:56 |
| vcunat | (and I wasn't doing anything else myself during that time) | 17:15:12 |
| vcunat | In general these path shenanigans are why I prefer to run most tests after the installation step (well, on Linux). | 17:16:40 |
| vcunat | There's still no explanation about the non-determinism of this. | 17:18:20 |
