problem with Documenter in packages depending on GAP.jl

[ThomasBreuer]

For a Julia package that depends on GAP.jl, I have created the setup for generating documentation with Documenter.jl, as described at https://juliadocs.github.io/Documenter.jl/stable/man/guide.
When the function makedocs gets called (in the file make.jl), I get a segmentation fault.
This crash disappears as soon as the using GAP statement is removed from the package in question.
Can anybody else reproduce this problem?

[mohamed-barakat]

I do not have a line called using GAP in HomalgProject, although I have a GAP.jl dependency:

https://github.com/homalg-project/HomalgProject.jl

I use Documenter.jl and everything is fine for me.

[fingolfin]

@ThomasBreuer nope; but perhaps you can link to the repository with the problematic code? Also, which version of Julia / GAP.jl / etc. is that, and on what OS/arch?

Slightly offtopic, but: I also am hoping that @ThomasBreuer and @frankluebeck will setup Documenter for GAP.jl itself, too. Doing that would likely trigger the same issue, so if somebody sets up a PR with this, then I'd be happy to debug the issue based on that code.

[fingolfin]

So I set up some minimal Documenter.jl integration for GAP.jl, and with that can indeed reproduce a crash. I get this backtrace:

julia> include("make.jl")
[ Info: Precompiling Documenter [e30172f5-a6a5-5a46-863b-614d45cd2de4]
[ Info: Precompiling GAP [c863536a-3901-11e9-33e7-d5cd0df7b904]
Adding path /Users/mhorn/.julia/packages/GAP/Tmarw/gap/.libs to DL_LOAD_PATH
 ┌───────┐   GAP 4.dev of today
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-apple-darwin18.7.0-julia64-kv7
 Configuration:  gmp 6.1.2, Julia GC, Julia 1.3.1, readline
 Loading the library and packages ...
 Packages:   GAPDoc 1.6.3, PrimGrp 3.4.0, SmallGrp 1.4.1, TransGrp 2.0.4
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'

signal (11): Segmentation fault: 11
in expression starting at none:3
getproperty at ./Base.jl:15 [inlined]
supertype at ./operators.jl:45 [inlined]
_subtypes at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/InteractiveUtils.jl:188
_subtypes at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/InteractiveUtils.jl:203
_subtypes at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/InteractiveUtils.jl:203
_subtypes_in at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/InteractiveUtils.jl:218
subtypes at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/InteractiveUtils.jl:240 [inlined]
dispatch at /Users/mhorn/.julia/packages/Documenter/HmOsT/src/Utilities/Selectors.jl:165
#2 at /Users/mhorn/.julia/packages/Documenter/HmOsT/src/Documenter.jl:237 [inlined]
cd at ./file.jl:104
#makedocs#1 at /Users/mhorn/.julia/packages/Documenter/HmOsT/src/Documenter.jl:236
#makedocs at ./none:0
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1631 [inlined]
do_call at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:328
eval_body at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:0
jl_interpret_toplevel_thunk_callback at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:888
unknown function (ip: 0xfffffffffffffffe)
unknown function (ip: 0x12d8d8d0f)
unknown function (ip: 0x8)
jl_interpret_toplevel_thunk at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:897
jl_toplevel_eval_flex at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:814
jl_parse_eval_all at /Users/julia/buildbot/worker/package_macos64/build/src/ast.c:873
jl_load at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:878 [inlined]
jl_load_ at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:885
include at ./boot.jl:328 [inlined]
include_relative at ./loading.jl:1105
include at ./Base.jl:31
include at ./client.jl:424
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1631 [inlined]
do_call at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:328
eval_body at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:0
jl_interpret_toplevel_thunk_callback at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:888
unknown function (ip: 0xfffffffffffffffe)
unknown function (ip: 0x10f78e40f)
unknown function (ip: 0xffffffffffffffff)
jl_interpret_toplevel_thunk at /Users/julia/buildbot/worker/package_macos64/build/src/interpreter.c:897
jl_toplevel_eval_flex at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:814
jl_toplevel_eval_flex at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:764
jl_toplevel_eval at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:823 [inlined]
jl_toplevel_eval_in at /Users/julia/buildbot/worker/package_macos64/build/src/toplevel.c:843
eval at ./boot.jl:330
eval_user_input at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/REPL/src/REPL.jl:86
run_backend at /Users/mhorn/.julia/packages/Revise/S7mrl/src/Revise.jl:1057
#85 at ./task.jl:333
jl_apply at /Users/julia/buildbot/worker/package_macos64/build/src/./julia.h:1631 [inlined]
start_task at /Users/julia/buildbot/worker/package_macos64/build/src/task.c:659
Allocations: 25285517 (Pool: 25260415; Big: 25102); GC: 30
Segmentation fault: 11

Note that at the top of the call stack, it messes around with subtypes and supertypes... So my suspicion is that our "foreign type" ForeignGAP.MPtr is somehow involved; as in, some code tries to interact with it and stumbles over the fact that "foreign types" are different than other Julia types.

In the very worst case, my "swizzle the super type" hack is cause of the problem, but I don't think that's very likely, given that here we start GAP from Julia, so no swizzling should happen. Anyway, CC to @rbehrends in case he has a quick idea.

[fingolfin]

Ah, of course: we now are not setting any super type for our bag types, but all types are supposed to have a super type. This will require a fix in the GAP kernel. I'll open a PR for that right away.