Segfaulting with mutually recursive linked lists

I’ve been building a new phylogenetic tree representation in Julia which uses mutually recursive linked lists to store a tree as linked nodes and branches. I know about handle mutually-circular type declarations · Issue #269 · JuliaLang/julia · GitHub and the fact that we can’t do forward declarations yet, so I reference the nodes and branches from each other using abstract base classes. The code is in a PR here - https://github.com/richardreeve/Phylo.jl/pull/16 - and at the moment is definitely WIP. However it works up to a point on Julia v0.6.4, but segfaults on v1.0.2… I’m wondering if anyone has any suggestions what’s going on, and whether this is a julia bug as it doesn’t happen at compile time - it just crashes the REPL later, e.g. by typing “using Phylo” and then hitting return a couple of times:

julia> using Phylo

julia> 
Segmentation fault: 11
Internal error: encountered unexpected error in runtime:
StackOverflowError()
subtype_ccheck at /Users/osx/buildbot/slave/package_osx64/build/src/subtype.c:451
var_lt at /Users/osx/buildbot/slave/package_osx64/build/src/subtype.c:506
exists_subtype at /Users/osx/buildbot/slave/package_osx64/build/src/subtype.c:1079 [inlined]
forall_exists_subtype at /Users/osx/buildbot/slave/package_osx64/build/src/subtype.c:1107
subtype_ccheck at /Users/osx/buildbot/slave/package_osx64/build/src/subtype.c:461
var_lt at /Users/osx/buildbot/slave/package_osx64/build/src/subtype.c:506

... [3MB of repeats] ...

jl_type_infer at /Users/osx/buildbot/slave/package_osx64/build/src/gf.c:275
jl_compile_method_internal at /Users/osx/buildbot/slave/package_osx64/build/src/gf.c:1786
jl_fptr_trampoline at /Users/osx/buildbot/slave/package_osx64/build/src/gf.c:1830
bracketed_paste at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:1920
jl_fptr_trampoline at /Users/osx/buildbot/slave/package_osx64/build/src/gf.c:1831
#55 at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/REPL.jl:901
jl_fptr_trampoline at /Users/osx/buildbot/slave/package_osx64/build/src/gf.c:1831
jl_apply at /Users/osx/buildbot/slave/package_osx64/build/src/./julia.h:1537 [inlined]
jl_f__apply at /Users/osx/buildbot/slave/package_osx64/build/src/builtins.c:556
jl_f__apply_latest at /Users/osx/buildbot/slave/package_osx64/build/src/builtins.c:594
#invokelatest#1 at ./essentials.jl:697 [inlined]
invokelatest at ./essentials.jl:696 [inlined]
#27 at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:1319
prompt! at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:2360
run_interface at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/LineEdit.jl:2263
run_frontend at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/REPL.jl:1034
run_repl at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.0/REPL/src/REPL.jl:191
#719 at ./logging.jl:309
jfptr_#719_5936.clone_1 at /Users/richardr/Applications/Julia-1.0.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jl_apply at /Users/osx/buildbot/slave/package_osx64/build/src/./julia.h:1537 [inlined]
jl_f__apply at /Users/osx/buildbot/slave/package_osx64/build/src/builtins.c:556
jl_f__apply_latest at /Users/osx/buildbot/slave/package_osx64/build/src/builtins.c:594
#invokelatest#1 at ./essentials.jl:697 [inlined]
invokelatest at ./essentials.jl:696 [inlined]
macro expansion at ./logging.jl:306 [inlined]
run_main_repl at ./client.jl:334
exec_options at ./client.jl:246
_start at ./client.jl:425
true_main at /Users/richardr/bin/julia-1.0 (unknown line)
main at /Users/richardr/bin/julia-1.0 (unknown line)

It seems to do it somewhat non-deterministically - if I paste multiple lines into the REPL, I can sometime get it to do quite a bit, but not if I do one line at a time, and I wonder whether it’s the garbage collector getting tied up in the recursive data structures, but I have no reason for saying that beyond the fact that it’s crashing at different times on different runs when it’s idle… any thoughts?

1 Like