Oscar.build() fails due to GAP's "foreign Julia type" not being serializable

[edgarcosta]

Describe the bug
Oscar.build() fails

To Reproduce
Steps to reproduce the behavior, please provide a code snippet that triggers
the bug.

using Oscar;
Oscar.build();

then here are some possible output:
https://gist.github.com/edgarcosta/3b91f9feefbe239201ef3d33ff5279a9
https://gist.github.com/edgarcosta/60b0792861968c4cd7bd5ec02f3a42b7

it is unclear to me if this is converging or not, but I'm past my 10th iteration of calling Oscar.build()

Expected behavior
Oscar.build() to successfully terminate

System :

julia> Oscar.versioninfo(full=true)
OSCAR version 0.9.0
  combining:
    AbstractAlgebra.jl   v0.26.0
    GAP.jl               v0.8.1
    Hecke.jl             v0.14.4
    Nemo.jl              v0.31.1
    Polymake.jl          v0.7.2
    Singular.jl          v0.10.2
  building on:
    Antic_jll               v0.200.501+0
    Arb_jll                 v200.2200.0+0
    Calcium_jll             v0.400.102+0
    FLINT_jll               v200.800.500+0
    GAP_jll                 v400.1192.2+1
    Singular_jll            v403.1.300+0
    libpolymake_julia_jll   v0.8.0+2
    libsingular_julia_jll   v0.23.1+0
    msolve_jll              v0.2.3+1
    polymake_jll            v400.600.0+0
See `]st -m` for a full list of dependencies.

Julia Version 1.7.3
Commit 742b9abb4d (2022-05-06 12:58 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU @ 2.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, cascadelake)
Official https://julialang.org/ release

Additional context
My goal is simply to speed up the loading time of Oscar, as the 30 seconds at the beginning of each session is utterly painful.
I can recreate this in two independent servers, but the logs posted above are from just one server.

[thofma]

Thanks for the report!

I have looked a bit into it. The error persists even if Oscar is stripped down to

module Oscar
end

The error was gone once I removed GAP.jl as a dependency. Indeed, just doing

julia> PackageCompiler.create_sysimage([:GAP], sysimage_path="bla")

results in

⠋ [00m:08s] PackageCompiler: compiling incremental system image
signal (11): Segmentation fault
in expression starting at /tmp/jl_jWNKliF8x6:18
jl_unwrap_unionall at /disk2/home/bla/repositories/julia/src/jltypes.c:1077
jl_deserialize_value_any at /disk2/home/bla/repositories/julia/src/dump.c:2038 [inlined]
jl_deserialize_value at /disk2/home/bla/repositories/julia/src/dump.c:2193
jl_deserialize_datatype at /disk2/home/bla/repositories/julia/src/dump.c:1488 [inlined]
jl_deserialize_value at /disk2/home/bla/repositories/julia/src/dump.c:2190
[...]

(This is with a fresh julia master and the recent version of PackageCompiler).
CC: @fingolfin @ThomasBreuer

I had a very artificial look and sprinkled some jl_ calls in dump.c. It seems there is value/type serialized, which fails to deserialize.

[fingolfin]

I am looking into it

[fingolfin]

Just to say: this is fixed in Julia 1.9 (which is currently in beta, and hopefully will be released soon; it has exciting improvements, like caching of native code, which reduces the need for PackageCompiler a bit, at least for me)