Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Precompiling Bio.jl crashed on recent master branch. #16471

Closed
bicycle1885 opened this issue May 20, 2016 · 3 comments · Fixed by #16745
Closed

Precompiling Bio.jl crashed on recent master branch. #16471

bicycle1885 opened this issue May 20, 2016 · 3 comments · Fixed by #16745
Labels
compiler:precompilation Precompilation of modules

Comments

@bicycle1885
Copy link
Member

Precompiling the master branch of Bio.jl package crashes with segmentation fault. This is reproducible both on OSX and on Linux (logs of Travis CI are here: https://travis-ci.org/BioJulia/Bio.jl/jobs/131278787, https://travis-ci.org/BioJulia/Bio.jl/jobs/131278801). This is also reproducible on my local machine (BioJulia/Bio.jl#191). The smallest reproducing code would be:

julia> Pkg.clone("https://github.com/BioJulia/Bio.jl.git")

julia> using Bio

When I disabled precompile with --compilecache=no flag, the Bio module was successfully loaded.

@tkelman tkelman added the compiler:precompilation Precompilation of modules label May 20, 2016
@bicycle1885
Copy link
Member Author

Applying the following patch to this commit can suppress the segfault:

diff --git a/src/precompile.jl b/src/precompile.jl
index 7872899..e56127b 100644
--- a/src/precompile.jl
+++ b/src/precompile.jl
@@ -9,9 +9,9 @@ if VERSION < v"0.5-"
     precompile(Base.open, (ASCIIString, Type{Seq.FASTQ},))
     precompile(Base.open, (ASCIIString, Type{Intervals.BED},))
 else
-    precompile(Base.open, (String, Type{Seq.FASTA},))
-    precompile(Base.open, (String, Type{Seq.FASTQ},))
-    precompile(Base.open, (String, Type{Intervals.BED},))
+    #precompile(Base.open, (String, Type{Seq.FASTA},))
+    #precompile(Base.open, (String, Type{Seq.FASTQ},))
+    #precompile(Base.open, (String, Type{Intervals.BED},))
 end
 precompile(Base.read, (Seq.FASTAParser{Seq.BioSequence},))
 precompile(Base.read, (Seq.FASTAParser{Seq.DNASequence},))

@Keno
Copy link
Member

Keno commented May 21, 2016

This one is quite reproducible. Seems to be a serialization issue (cc @vtjnash maybe):

(rr) list
1614                int ref_only = read_uint8(s);
1615                if (ref_only) {
1616                    jl_module_t *m = (jl_module_t*)jl_deserialize_value(s, NULL);
1617                    jl_sym_t *sym = (jl_sym_t*)jl_deserialize_value(s, NULL);
1618                    jl_datatype_t *dt = (jl_datatype_t*)jl_get_global(m, sym);
1619                    assert(jl_is_datatype(dt));
1620                    jl_value_t *v = (jl_value_t*)dt->name;
1621                    if (usetable)
1622                        backref_list.items[pos] = v;
1623                    return v;
(rr) p jl_(m)
Base
$10 = void
(rr) p jl_(sym)
:#kw##open
$11 = void
(rr) p dt
$12 = (jl_datatype_t *) 0x0

@vtjnash
Copy link
Member

vtjnash commented May 21, 2016

It looks like a new type (#kw##open#) was created on-the-fly for Base.#open, which isn't something incremental serialization knows how to handle @JeffBezanson

vtjnash added a commit that referenced this issue Jun 3, 2016
the kwftype may not be lazy-created yet
so store instead a reference to the primary type
and potentially rebuild the kwftype on-demand

fix #16471
vtjnash added a commit that referenced this issue Jun 3, 2016
the kwftype may not be lazy-created yet
so store instead a reference to the primary type
and potentially rebuild the kwftype on-demand

fix #16471
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:precompilation Precompilation of modules
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants