Error 139 when building ocaml.5.5.0 on Ubuntu 26.04

I am trying to give 5.5.0 a look but I cannot build it on my machine.

opam switch create 5.5.0 gives the following error :

=== ERROR while compiling ocaml.5.5.0========================================#
# context 2.5.0 | linux/x86_64 | ocaml-base-compiler.5.5.0 | opam - opam
73ed5b785d42
# path ~/.opam/5.5.0/.opam-switch/build/ocaml.5.5.0
# command ~/.opam/opam-init/hooks/sandbox.sh build ocaml gen_ocaml_config.ml 5.5.0 ocaml 5.5.0 false
# exit-code 139
# env-file ~/.opam/log/ocaml-157660-f4b186.env
# output-file ~/.opam/log/ocaml-157660-f4b186.out

The sandbox.sh script does not contain an exit 139, so I suspect it is coming from a process called by it. The out file is empty and the env file is below.

ASAN_OPTIONS=detect_leaks=0,exitcode=0
CAML_LD_LIBRARY_PATH=
CDPATH=
COLORFGBG=15;0
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DEBUGINFOD_URLS=https://debuginfod.ubuntu.com
DESKTOP_SESSION=plasma
DISPLAY=:0
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/yann/.gtkrc-2.0:/home/yann/.config/gtkrc-2.0
GTK_RC_FILES=/etc/gtk/gtkrc:/home/yann/.gtkrc:/home/yann/.config/gtkrc
HOME=/home/yann
ICEAUTHORITY=/run/user/1000/iceauth_rjiMAa
IM_CONFIG_ENTRY=profile
INVOCATION_ID=2cfb64d435264f2283dfda0e123c241b
JOURNAL_STREAM=10:26791
KDE_APPLICATIONS_AS_SCOPE=1
KDE_FULL_SESSION=true
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=6
KONSOLE_DBUS_ACTIVATION_COOKIE=CYIEIq7V/JEq2Iy/Ltzx7TyEzROcT8CgRYJd0Vdstpo=
KONSOLE_DBUS_SERVICE=:1.200
KONSOLE_DBUS_SESSION=/Sessions/1
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_VERSION=251203
LANG=fr_FR.UTF-8
LANGUAGE=fr
LC_ADDRESS=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_MONETARY=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LC_NUMERIC=fr_FR.UTF-8
LC_PAPER=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
LESSCLOSE=/usr/bin/lesspipe %s %s
LESSOPEN=| /usr/bin/lesspipe %s
LOGNAME=yann
LSAN_OPTIONS=detect_leaks=0,exitcode=0
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.lz4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;31:.zip=01;31:.z=01;31:.dz=01;31:.gz=01;31:.lrz=01;31:.lz=01;31:.lzo=01;31:.xz=01;31:.zst=01;31:.tzst=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.cab=01;31:.wim=01;31:.swm=01;31:.dwm=01;31:.esd=01;31:.avif=01;35:.jpg=01;35:.jpeg=01;35:.mjpg=01;35:.mjpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.webp=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.oga=00;36:.opus=00;36:.spx=00;36:.xspf=00;36:~=00;90:#=00;90:.bak=00;90:.old=00;90:.orig=00;90:.part=00;90:.rej=00;90:.swp=00;90:.tmp=00;90:.dpkg-dist=00;90:.dpkg-old=00;90:.ucf-dist=00;90:.ucf-new=00;90:.ucf-old=00;90:.rpmnew=00;90:.rpmorig=00;90:.rpmsave=00;90:
MAKEFLAGS=
MAKELEVEL=
MANAGERPID=2325
MANAGERPIDFDID=4395
MANPATH=:/home/yann/.opam/5.5.0/man
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service/memory.pressure
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
OCAMLRUNPARAM=b
OCAMLTOP_INCLUDE_PATH=
OCAML_TOPLEVEL_PATH=
OPAMCLI=2.0
OPAMROOT=/home/yann/.opam
OPAMSWITCH=5.5.0
OPAM_LAST_ENV=
OPAM_PACKAGE_NAME=ocaml
OPAM_PACKAGE_VERSION=5.5.0
OPAM_SWITCH_PREFIX=/home/yann/.opam/5.5.0
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
PATH=/home/yann/.opam/5.5.0/bin:/opt/yann/bin:/opt/yann/texlive/bin/x86_64-linux:/home/yann/.cargo/bin:/home/yann/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/yann/.local/bin
PROFILEHOME=
PWD=/home/yann
QT_ACCESSIBILITY=1
QT_WAYLAND_RECONNECT=1
SESSION_MANAGER=local/precision:@/tmp/.ICE-unix/2631,unix/precision:/tmp/.ICE-unix/2631
SHELL=/bin/bash
SHELL_SESSION_ID=c869ff0491b84d3690f005ce2fa226cd
SHLVL=1
SSH_ASKPASS=/usr/bin/ksshaskpass
SSH_ASKPASS_REQUIRE=prefer
SSH_AUTH_SOCK=/run/user/1000/openssh_agent
SYSTEMD_EXEC_PID=2652
TERM=xterm-256color
USER=yann
WAYLAND_DISPLAY=wayland-0
WINDOWID=99381111599792
XAUTHORITY=/run/user/1000/xauth_BmkkBk
XDG_CONFIG_DIRS=/home/yann/.config/kdedefaults:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings
XDG_CURRENT_DESKTOP=KDE
XDG_DATA_DIRS=/home/yann/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop
XDG_MENU_PREFIX=plasma-
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=3
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=wayland
XDG_VTNR=2
XKB_DEFAULT_LAYOUT=fr
XKB_DEFAULT_MODEL=pc105
_=/usr/bin/opam
_JAVA_AWT_WM_NONREPARENTING=1

In fact I cannot rebuild the 5.4.1 switch that I had been using, even after a full re-init of opam.

For what is worth, exit code 139 typically indicates a segmentation fault (shells often encode that as 128 + SIGSEGV = 139).

Cheers,
Nicolas

That could be a SIGSEGV. Check dmesg for any segfaults. Also try to see whether you can find a coredump (coredumpctl list, or check what /proc/sys/kernel/core_pattern is set to).

Also try booting an ISO from https://www.memtest.org/. Many years ago when a compiler (GCC in my case) started inexplicably segfaulting it was indeed due to faulty RAM (ever since then I only buy RAM with heatsinks).

You might be on point, as temperatures were very high last week and I did have some strange behaviours while remotely accessing the computer. The RAM looks good, but I will be checking CPU, GPU, SSD too.

The hardware seems good.

Opam manages to do

∗ installed base-bigarray.base
∗ installed base-threads.base
∗ installed base-unix.base
∗ installed compiler-cloning.enabled
∗ installed ocaml-options-vanilla.1
⬇ retrieved ocaml.5.5.0 (``https://opam.ocaml.org/cache``)
⬇ retrieved ocaml-compiler.5.5.0 (``https://opam.ocaml.org/cache``)
∗ installed ocaml-compiler.5.5.0
∗ installed ocaml-base-compiler.5.5.0

But running ~/.opam/default/bin/ocamlrun or ocaml or ocamlopt or ocamlopt.opt gives a segfault. Which is odd, because if I understand correctly, there should have been a process of compiling the ocaml compiler with an earlier version of itself, and that did not cause a segfault.

There is a coredump, but I have no idea what to do with it.

Now this is getting interesting : reminding that my home is encryptfs-encrypted, I thought maybe that could interfere (although it never did in earlier versions of Ubuntu, opam and OCaml). So I did opam init --root=/opt/yann/opam, this directory being not encrypted.

And it works !

The (faulty) binaries in ~/.opam have md5sums

9128ea9c8bfdde307e4cb9e2551d28e9  ocaml
80c6b84528c16d4ea79c3afc3a0be071  ocamlc
bf2f98bdc359021a6e2ed0a5149bdcd8  ocamlc.byte
3fd25b4d02798ede0e26f4304cb2c1e1  ocamlcmt
80c6b84528c16d4ea79c3afc3a0be071  ocamlc.opt
c8b8b11d0597297f26a2c4ae34ad58de  ocamlcp
42cb0b4eaaaa1f5f4fd4e73f2ce482a5  ocamldebug
6c0e037b2ff20e9fbdbfe7023f902a4e  ocamldep
530d669569d8e17c293a83eac81092b2  ocamldep.byte
6c0e037b2ff20e9fbdbfe7023f902a4e  ocamldep.opt
ad5aebd98c27ecf47100a6778f5885cd  ocamldoc
833faa2c003468b5aaaa6164a839eaf1  ocamldoc.opt
b39d34c6d9b56a9d864921ae799d6051  ocamllex
63a1f30507e137159a0048ff36124039  ocamllex.byte
b39d34c6d9b56a9d864921ae799d6051  ocamllex.opt
20cb42c925241924475004c53fa7442d  ocamlmklib
82d5a947ab71baab2816222d0372e09d  ocamlmktop
bd890163cef1dabd9061365807ce407d  ocamlobjinfo
ffe2ca72ae7905363b70c149074fc824  ocamlobjinfo.byte
bd890163cef1dabd9061365807ce407d  ocamlobjinfo.opt
d40aeb8bfabf0501511fa0a9fd028137  ocamlopt
75361ac011d21062adec6c672daba81f  ocamlopt.byte
d40aeb8bfabf0501511fa0a9fd028137  ocamlopt.opt
cba1037fc20aabbdf00c39ccbfd80d1b  ocamloptp
bd417a6836eff3f5b8c1090c71ffb37f  ocamlprof
454e603967b6018e692de129d64f9d77  ocamlrun
454e603967b6018e692de129d64f9d77  ocamlrun-a100
ed2aad72ad2d160865473bb4ba5c6bd6  ocamlrund
ed2aad72ad2d160865473bb4ba5c6bd6  ocamlrund-a100
e92a788ce942daa4cd23ec6b3601f53b  ocamlruni
e92a788ce942daa4cd23ec6b3601f53b  ocamlruni-a100
7023b7a07c35d5ee6d8499d70d170e26  ocamlyacc
454e603967b6018e692de129d64f9d77  x86_64-pc-linux-gnu-ocamlrun-a100
ed2aad72ad2d160865473bb4ba5c6bd6  x86_64-pc-linux-gnu-ocamlrund-a100
e92a788ce942daa4cd23ec6b3601f53b  x86_64-pc-linux-gnu-ocamlruni-a100

The md5sums of the binaries created in /opt/yann/opam are

bd7b298b543531d99d50013e082e76bc  ocaml
1e2e0eb1cc8d527cb76aadf601a04a24  ocamlc
cee072a78eccb61316f5a8959b27366d  ocamlc.byte
1208a38f3f40f68c2eff875a97aafdc0  ocamlcmt
1e2e0eb1cc8d527cb76aadf601a04a24  ocamlc.opt
6ddfc1038fbf81e7cfd8daa674957067  ocamlcp
02d80d39ba0255da19ff323575ff1a0d  ocamldebug
e3b609577e4e6b0706a4f4704538660f  ocamldep
37281a61c0a3b6f719f6f7d2b21713d3  ocamldep.byte
e3b609577e4e6b0706a4f4704538660f  ocamldep.opt
bd694ec504e130fbeb6b9461f4a93e3b  ocamldoc
3aec993306c33ba4b5958e8b87b4f14b  ocamldoc.opt
04636df94705b1b7cb0a6553fb897fbb  ocamllex
887f6315ad08ad3e315d08efb01a6b40  ocamllex.byte
04636df94705b1b7cb0a6553fb897fbb  ocamllex.opt
e0b5b093081671cd30b1503729032b16  ocamlmklib
3452ef3a57ff6591cbd40758417f2f9c  ocamlmktop
b60de9cb9543700c56d08ff97842c706  ocamlobjinfo
daa4bc6209b62c454953c1bedee832ae  ocamlobjinfo.byte
b60de9cb9543700c56d08ff97842c706  ocamlobjinfo.opt
2a77b83f4322bf20e94417552adf6817  ocamlopt
57d38786c0d93b5239cf0852b502c1ad  ocamlopt.byte
2a77b83f4322bf20e94417552adf6817  ocamlopt.opt
70bf33b73202f069c3f5654ded2788d1  ocamloptp
bfb2a3efec34c2291d03b3b14a961415  ocamlprof
1285a7781fb545163d0a953507f69ef1  ocamlrun
1285a7781fb545163d0a953507f69ef1  ocamlrun-a100
de2f47bc8b8039d97467e722fbae3ac0  ocamlrund
de2f47bc8b8039d97467e722fbae3ac0  ocamlrund-a100
d3877c231f831a7b6b9178d917a5a025  ocamlruni
d3877c231f831a7b6b9178d917a5a025  ocamlruni-a100
c14043999b9216eb431b667cbe8079eb  ocamlyacc
1285a7781fb545163d0a953507f69ef1  x86_64-pc-linux-gnu-ocamlrun-a100
de2f47bc8b8039d97467e722fbae3ac0  x86_64-pc-linux-gnu-ocamlrund-a100
d3877c231f831a7b6b9178d917a5a025  x86_64-pc-linux-gnu-ocamlruni-a100

If I create an empty /opt/yann/opam then do a symlink from ~/.opam to that, I can create the switch “normally” and the md5sums are the above.

So, while I am satisfied that I can create a working ocaml installation, I remain baffled by this. Can anybody try to reproduce this with an ad hoc encryptfs setup ?

Can you reproduce the same md5 when re creating ~/.opam from scratch on ecrytpfs ? (maybe it was a one time corruption of some component that is linked everywhere).

Otherwise, if you have activated filename encryption in ecryptfs, this limits filenames to 143 characters (instead of 255), the remaining one being used for ecryptfs metadata. So if some subprocess is creating too long a filename this could also explain it ?

I rm -rf ~/.opamed repeatadly yesterday, yes.

If I do in Python open("t"*150, "w") in my home dir, I get en error 36, filename too long. So I guess I would get that too if the opam switch creation did that.

Works fine with Linux 7.0.12-1-default on OpenSUSE Tumbleweed:

sudo modprobe ecryptfs
ecryptfs-setup-private
ecryptfs-mount-private
export OPAMROOT=$HOME/Private

Same steps on Ubuntu 26.04 result in exitcode 139 (with a 7.0.0-27-generic kernel).

The binaries are corrupted in some way:

gdb ./x86_64-pc-linux-gnu-ocamlrun-a100 
GNU gdb (Ubuntu 17.1-2ubuntu1) 17.1
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
❌ "/home/edwint/Private/default/bin/./x86_64-pc-linux-gnu-ocamlrun-a100": not in executable format: file format not recognized

They are fine on OpenSUSE:

gdb ./x86_64-pc-linux-gnu-ocamlrun-a100 
GNU gdb (GDB; openSUSE Tumbleweed) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./x86_64-pc-linux-gnu-ocamlrun-a100...
(gdb) quit

At first glance this appears to be a kernel bug (see below, it is not), although more investigation is needed into what produces the corrupted binary (i.e. whether it is a bug in the build process that doesn’t handle some ecryptfs limitation correctly).

Building from git inside Private/ shows that something goes wrong during make install.
make install DESTDIR=$PWD/tst produces the corrupted binaries, whereas make install DESTDIR=/tmp works. (the binaries also work in ecryptfs before installation, i.e. running runtime/ocamlrun ./ocaml -I stdlib works.

The binary on ecryptfs’s make install appears to be truncated:

ls tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100  -l /tmp/tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100 
-rwxr-xr-x 1 edwint edwint 2029544 Jun 29 09:41 /tmp/tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100
-rwxr-xr-x 1 edwint edwint 1914856 Jun 29 09:41 tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100

Although the actual contents is corrupted too:

cmp /tmp/tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100 tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100
/tmp/tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100 tst/usr/local/bin/x86_64-pc-linux-gnu-ocamlrun-b100 differ: byte 16385, line 37

It is the install program which corrupts it, cp is fine:

$ /usr/bin/install  runtime/ocamlrun ocamlrun.tst
$ ls -l runtime/ocamlrun ocamlrun.tst 
-rwxr-xr-x 1 edwint edwint 1914856 Jun 29 09:48 ocamlrun.tst
-rwxrwxr-x 1 edwint edwint 2029544 Jun 29 09:41 runtime/ocamlrun
$ cp runtime/ocamlrun ocamlrun.tst
$ ls -l runtime/ocamlrun ocamlrun.tst 
-rwxr-xr-x 1 edwint edwint 2029544 Jun 29 09:48 ocamlrun.tst
-rwxrwxr-x 1 edwint edwint 2029544 Jun 29 09:41 runtime/ocamlrun

This is perhaps a bug in install, which doesn’t handle an EINVAL from splice correctly:

openat(AT_FDCWD, "runtime/ocamlrun", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "ocamlrun.tst", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 4
pipe([5, 6])                            = 0
fcntl(5, F_SETPIPE_SZ, 1048576)         = 1048576
splice(3, NULL, 6, NULL, 131072, 0)     = 131072
splice(5, NULL, 4, NULL, 131072, 0)     = -1 EINVAL (Invalid argument)
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\264\1\0\0\0\0\0"..., 16384) = 16384
write(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\264\1\0\0\0\0\0"..., 16384) = 16384
....

(There is no EINVAL when copying to a regular destination).

This appears to be bug in coreutils-from-uutils, which is the Rust rewrite of coreutils.
OpenSUSE uses coreutils, which doesn’t have this bug.

It can be reproduced without ocaml:

$ yes foo | dd of=test bs=4K count=16
$ install ./test ./test-bad
$ echo $?
0
$ ls -l test test-bad
-rw-rw-r-- 1 edwint edwint 65536 Jun 29 09:56 test
-rwxr-xr-x 1 edwint edwint 16384 Jun 29 09:56 test-bad

@ysalmon
This is a data corruption bug that should be reported to the Ubuntu bug tracker, meanwhile I’d suggest to have backups of your home directory, in case other commands are buggy like this…
You’d probably be in a better position to test fixes for this than me, could you open that bugreport on the Ubuntu tracker?

Done : Bug #2158615 “install corrupts files on ecryptfs folders” : Bugs : coreutils-from package : Ubuntu

Thank you all for your help.

This is why I walked away from Ubuntu since 24.04, migration always cause errors.

But sadly, too many production server rely on it.