Change:
fails the build, because running the tests terminates with a segfault on unstable. Complete build log: Build succeeds. N/A N/A <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(henri): nixpkgs:
Bisected to
I just tried : it does not segfault, but it causes the test to hang.
It seems that there are at least two problems: the segfault in the test and the hanging test. I suggest reverting the upgrade back to version for now. Maybe has an idea or wants to report the issue upstream?
Well, there's a bunch of ways to start openmpi, with many many options and some combinations may lead to such segfault. I see that before the backtrace, there's an UCX error about the tcp interface not found. Then, the OFI BTL seems to be used. But OFI (open fabric interface) is meant to be used on computing nodes hosting a specific network interface. I suggest trying to force the mpi4py test to use the "VADER" or "SELF" interface: or You may also try or
That is true, but I think the default should just work and not segfault. You can make the tests in mpi4py pass by setting in its test phase, but I don't think this is a good solution. Rather should the auto-detect mechanism just work without crashing. EDIT: this could be an acceptable solution if the failure is specific to the builder's sandbox, but does not appear if used outside the sandbox.
Maybe let's start with adding to the test phase to get the ball rolling and improve further at a later time if necessary.
Isn't that just masking the problem? It then may just break at run time, which is could be super annoying for someone who does not know why this happens.
I see the libfabric update was just reverted although I wonder whether this will work out in the long run. An update will be necessary sooner or later.
I agree, that we should update libfabric at some point, but at least we have everything in a well working state right now. IMHO that should have higher priority than updating at any cost. I would expect that we can either find a proper solution to fix the problem or that, ideally, libfabric is fixed upstream. Is someone willing to report this issue upstream?
I reported it here

Discussion:
<del> { lib , stdenv , fetchFromGitHub , pkg-config , autoreconfHook , enablePsm2 ? (stdenv.isx86_64 && stdenv.isLinux) , libpsm2 , enableOpx ? (stdenv.isx86_64 && stdenv.isLinux) , libuuid , numactl }: </del> <ins> { lib, stdenv, fetchFromGitHub, pkg-config, autoreconfHook, libpsm2 , enablePsm2 ? (stdenv.isx86_64 && stdenv.isLinux) }: </ins> stdenv.mkDerivation rec { pname = "libfabric"; <del> version = "1.17.0"; </del> <ins> version = "1.15.1"; </ins> enableParallelBuilding = true;

owner = "ofiwg"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-tXfAn8hkasA2UuA4/8dOE3EcORyJo/A33TtSNdzDXD8="; </del> <ins> sha256 = "sha256-uL3L9k9yqdZXQmR1zi8OEIGLAZ8cf7EBnlDhetaMA08="; </ins> }; nativeBuildInputs = [ pkg-config autoreconfHook ]; <del> buildInputs = lib.optionals enableOpx [ libuuid numactl ] ++ lib.optional enablePsm2 [ libpsm2 ]; </del> <ins> buildInputs = lib.optional enablePsm2 libpsm2; </ins> <del> configureFlags = [ (if enablePsm2 then "--enable-psm2=${libpsm2}" else "--disable-psm2") (if enableOpx then "--enable-opx" else "--disable-opx") ]; </del> <ins> configureFlags = [ (if enablePsm2 then "--enable-psm2=${libpsm2}" else "--disable-psm2") ]; </ins> meta = with lib; { homepage = "https://ofiwg.github.io/libfabric/";