`make setup` segfault
Closed this issue · 5 comments
on a vanilla goblint checkout make setup fails on the first run with
#=== ERROR while compiling stdune.3.14.0 ======================================#
# context 2.1.5 | linux/x86_64 | ocaml-option-flambda.1 ocaml-variants.4.14.0+options | https://opam.ocaml.org#e3ff9f97
# path /tmp/analyzer/_opam/.opam-switch/build/stdune.3.14.0
# command ~/.opam/opam-init/hooks/sandbox.sh build dune build -p stdune -j 7 @install
# exit-code 1
# env-file ~/.opam/log/stdune-65947-bc2de1.env
# output-file ~/.opam/log/stdune-65947-bc2de1.out
### output ###
# File "otherlibs/stdune/src/.stdune.objs/native/_unknown_", line 1, characters 0-0:
# (cd _build/default && /tmp/analyzer/_opam/bin/ocamlopt.opt -w -40 -alert -unstable -g -I otherlibs/stdune/src/.stdune.objs/byte -I otherlibs/stdune/src/.stdune.objs/native -I /tmp/analyzer/_opam/lib/csexp -I /tmp/analyzer/_opam/lib/dyn -I /tmp/analyzer/_opam/lib/ordering -I /tmp/analyzer/_opam/lib/pp -I otherlibs/stdune/dune_filesystem_stubs/.dune_filesystem_stubs.objs/byte -I otherlibs/stdun[...]
# Command got signal SEGV.
#=== ERROR while compiling base.v0.16.3 =======================================#
# context 2.1.5 | linux/x86_64 | ocaml-option-flambda.1 ocaml-variants.4.14.0+options | https://opam.ocaml.org#e3ff9f97
# path /tmp/analyzer/_opam/.opam-switch/build/base.v0.16.3
# command ~/.opam/opam-init/hooks/sandbox.sh build dune build -p base -j 7
# exit-code 1
# env-file ~/.opam/log/base-65947-51aea5.env
# output-file ~/.opam/log/base-65947-51aea5.out
### output ###
# File "src/.base.objs/byte/_unknown_", line 1, characters 0-0:
# (cd _build/default && /tmp/analyzer/_opam/bin/ocamlc.opt -w -40 -g -bin-annot -I src/.base.objs/byte -I /tmp/analyzer/_opam/lib/sexplib0 -I compiler-stdlib/src/.caml.objs/byte -I hash_types/src/.base_internalhash_types.objs/byte -I shadow-stdlib/src/.shadow_stdlib.objs/byte -no-alias-deps -open Base__ -o src/.base.objs/byte/base__Set_intf.cmo -c -impl src/set_intf.ml)
# Command got signal SEGV.
a second run of make setup then succeeds. Unfortunately, this is rather inconsistent; the next time I tried, I got a similar thing failing to build build ocaml-variants 4.14.0+options.
Anyway, I continue with make dev.
Then executing make test gives me
File "src/sites/sites_dune/dune", line 8, characters 13-22:
8 | (libraries dune-site))
^^^^^^^^^
Error: Library "dune-site" not found.
-> required by library "goblint.sites.dune" in
_build/default/src/sites/sites_dune
-> required by executable cfgDot in tests/regression/cfg/util/dune:2
-> required by _build/default/tests/regression/cfg/util/cfgDot.exe
-> required by _build/default/tests/regression/.bin/cfgDot
-> required by %{bin:cfgDot} at tests/regression/00-sanity/dune:8
-> required by alias tests/regression/00-sanity/runtest
File "unittest/dune", line 5, characters 20-32:
5 | (libraries ounit2 qcheck-ounit goblint.std goblint.common goblint.lib goblint.constraint goblint.solver goblint.cdomain.value goblint.sites.dune goblint.build-info.dune)
^^^^^^^^^^^^
Error: Library "qcheck-ounit" not found.
-> required by _build/default/unittest/mainTest.exe
-> required by alias unittest/runtest in unittest/dune:4
make: *** [Makefile:4: test] Error 1
which I can fix manually via opam install dune-site qcheck-ounit .
Not having dune-site or qcheck-ounit is not surprising if all the dependencies weren't installed before.
The odd thing is compilation of stdune or base segfaulting in the OCaml compiler. I don't think it has anything to do with Goblint.
Could it be a matter of the -j 7 parameter? This may explain the inconsistency of the installation failures?
using a very defensive opam switch -j 2 in make.sh for opam_setup consistently succeeds on my 8 core 16 threads machine. Of course this is not a goblint issue per se, but machines with more then 4 cores might become more frequent... maybe limiting the number of jobs in an opam run is beneficial?
dune-site seems to install quite fine, when I install all dependencies. qcheck-ounit however, I have to install manually each time.
After a morning of try-and-fail, I think that something in the opam system is broken on my machine, so I will close this particular one, since the segfault is misleading. Instead, there still is #1384
rm -rf ~/.opam did the job 🤦