Description of problem: The ocaml-dune package started failing to build from source on i386 only when gcc-13.0.1-0.4 landed in the repos (see bug 2168932). The immediate problem is a segfault inside a call to pthread_sigmask: pthread_sigmask(SIG_SETMASK, &saved_procmask, NULL); Although saved_procmask is a local variable, gdb shows that pthread_sigmask receives the number 9 as its second argument. The first and third arguments are passed correctly. Downgrading to gcc-13.0.1-0.3 makes the issue go away. Adding -fno-inline-functions to the build flags also makes the issue go away. I tried to make a reduced test case to illustrate the problem. The code in question (vendor/spawn/src/spawn_stubs.c) has calls into the OCaml runtime, mostly for memory handling. I tried to replace all such calls with generic C library functionality. The resulting program does not segfault. I suspect that means that the OCaml C API practice of converting back and forth between pointers and integers, and bit shifting in the process, somehow plays a role. At this point, I don't know how to produce a small reproducer. Version-Release number of selected component (if applicable): gcc-13.0.1-0.4.fc39.i686 How reproducible: Always Steps to Reproduce: 1. Build the ocaml-dune package for Rawhide on i386 2. 3. Actual results: The bootstrap dune binary segfaults. Expected results: No segfaults. Additional info:
I can't even get dune to compile on x86-64. It fails at: + /usr/bin/make -O -j24 V=1 VERBOSE=1 release ocamlc -output-complete-exe -w -24 -g -o .duneboot.exe -I boot unix.cma boot/libs.ml boot/duneboot.ml ./.duneboot.exe Internal error, please report upstream including the contents of _build/log. Description: ("Unexpected find result", { found = Not_found; lib.name = "pp" }) Raised at Stdune__code_error.raise in file "otherlibs/stdune/src/code_error.ml", line 11, characters 30-62 Called from Fiber__scheduler.exec in file "otherlibs/fiber/src/scheduler.ml", line 73, characters 8-11 -> required by ("<unnamed>", ()) -> required by ("<unnamed>", ()) -> required by ("<unnamed>", ()) -> required by ("load-dir", In_build_dir "default/src/fsevents/bin") -> required by ("toplevel", ()) I must not crash. Uncertainty is the mind-killer. Exceptions are the little-death that brings total obliteration. I will fully express my cases. Execution will pass over me and through me. And when it has gone past, I will unwind the stack along its path. Where the cases are handled there will be nothing. Only I will remain. make: *** [Makefile:47: release] Error 1
As for the original bug, I don't think there's an easy way to reproduce it without a full i686 environment. In theory this might work: $ setarch i386 fedpkg local but in practice it fails because of lack of OCaml dependencies compiled for i686 like ocaml-pp.
FEDORA-2023-213a7f0317 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-213a7f0317
Proposed as a Blocker for 38-beta by Fedora user jakub using the blocker tracking app because: An important wrong-code bug has been introduced in gcc-13.0.1-0.4.fc38 (tagged into stable Feb 17), which results in likely miscompilation of all code that uses vfork. I'm afraid every day the fixed gcc-13.0.1-0.5.fc38 isn't tagged into f38 means risk of further miscompiled packages.
Proposed as F38 beta blocker. Details in https://gcc.gnu.org/PR108868 and https://gcc.gnu.org/PR108691
Proposed as a Freeze Exception for 38-beta by Fedora user frantisekz using the blocker tracking app because: Proposing as a FE, this will have the same effect as Blocker in this case (we have a fix), but makes things wording-wise easier procedurally.
FEDORA-2023-213a7f0317 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-213a7f0317 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
+4 FE in https://pagure.io/fedora-qa/blocker-review/issue/1045 , marking accepted FE.
FEDORA-2023-213a7f0317 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.