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

Reliable segfault on precompiling Images #16301

Closed
timholy opened this issue May 10, 2016 · 2 comments · Fixed by #16391
Closed

Reliable segfault on precompiling Images #16301

timholy opened this issue May 10, 2016 · 2 comments · Fixed by #16391

Comments

@timholy
Copy link
Sponsor Member

timholy commented May 10, 2016

Using Images commit fbf9e98112c88355fc0b6c986995b7e9875ebcba, and

julia> versioninfo()
Julia Version 0.5.0-dev+4015
Commit 0eb3875* (2016-05-10 17:38 UTC)
DEBUG build
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, sandybridge)

(NB: this is a debug build)

I get a segfault from dump.c:

julia-0.5: /home/tim/src/julia-0.5/src/dump.c:2222: jl_recache_type: Assertion `t->uid != 0' failed.

signal (6): Aborted
while loading no file, in expression starting on line 0
gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x7f99e1da1b85)
__assert_fail at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
jl_recache_type at /home/tim/src/julia-0.5/src/dump.c:2222
jl_recache_types at /home/tim/src/julia-0.5/src/dump.c:2273
_jl_restore_incremental at /home/tim/src/julia-0.5/src/dump.c:2330
jl_restore_incremental at /home/tim/src/julia-0.5/src/dump.c:2379
_require_from_serialized at ./loading.jl:174
require at ./loading.jl:365
unknown function (ip: 0x7f99dea1f016)
jl_call_method_internal at /home/tim/src/julia-0.5/src/julia_internal.h:76
jl_apply_generic at /home/tim/src/julia-0.5/src/gf.c:1561
jl_apply at /home/tim/src/julia-0.5/src/julia.h:1382
eval_import_path_ at /home/tim/src/julia-0.5/src/toplevel.c:375
eval_import_path at /home/tim/src/julia-0.5/src/toplevel.c:402
jl_toplevel_eval_flex at /home/tim/src/julia-0.5/src/toplevel.c:451
jl_toplevel_eval at /home/tim/src/julia-0.5/src/toplevel.c:557
jl_toplevel_eval_in_warn at /home/tim/src/julia-0.5/src/builtins.c:547
jl_toplevel_eval_in at /home/tim/src/julia-0.5/src/builtins.c:514
eval at ./boot.jl:230
unknown function (ip: 0x7f99de987070)
jl_call_method_internal at /home/tim/src/julia-0.5/src/julia_internal.h:76
jl_apply_generic at /home/tim/src/julia-0.5/src/gf.c:1561
[inline] at ./REPL.jl:3
eval_user_input at ./REPL.jl:62
unknown function (ip: 0x7f97dcbfb5a6)
jl_call_method_internal at /home/tim/src/julia-0.5/src/julia_internal.h:76
jl_apply_generic at /home/tim/src/julia-0.5/src/gf.c:1561
[inline] at ./REPL.jl:92
#1 at ./event.jl:46
unknown function (ip: 0x7f99e3e5b52f)
jl_call_method_internal at /home/tim/src/julia-0.5/src/julia_internal.h:76
jl_apply_generic at /home/tim/src/julia-0.5/src/gf.c:1561
jl_apply at /home/tim/src/julia-0.5/src/julia.h:1382
start_task at /home/tim/src/julia-0.5/src/task.c:253
unknown function (ip: 0xffffffffffffffff)
Allocations: 4340062 (Pool: 4338379; Big: 1683); GC: 9
Aborted (core dumped)

This doesn't happen if I set __precompile__(false), or just directly include("Images.jl").

I've reproduced this on two machines, and it happens every time at the same place. It's not a complete corruption, because

(gdb) call jl_(t)
Images.Clamp{ColorTypes.BGRA{#T<:Any}}
@vtjnash
Copy link
Sponsor Member

vtjnash commented May 10, 2016

I think you already reported this in #12096? Jeff fixed this then reverted the fix last summer, so I'm hoping he can look into this and explain what's broken.

timholy referenced this issue May 10, 2016
@timholy
Copy link
Sponsor Member Author

timholy commented May 10, 2016

Your memory is so much better than mine.

@timholy timholy closed this as completed May 10, 2016
vtjnash added a commit that referenced this issue May 11, 2016
corrupt them before instead :)
when it's less likely someone is looking

fix #12238
fix #16301
vtjnash added a commit that referenced this issue May 12, 2016
corrupt them before instead :)
when it's less likely someone is looking

fix #12238
fix #16301
vtjnash added a commit that referenced this issue May 13, 2016
has-typevars is called pretty heavily during intersection and subtyping
so it can be a hot-path

fix lowering of TypeVar in TypeConstructor typealias expression:
instead have lowering emit the correct TypeVar expression instead of mutating (aka corrupting)
the immutable TypeVars in the TypeConstructor constructor

avoid corrupting immutable TypeVar after building a DataType for them:
instead have lowering emit the correct TypeVar expression
instead of modifying them in the DataType constructor
fix #12238
fix #16301
vtjnash added a commit that referenced this issue May 16, 2016
fix #16301
doesn't completely fix #12096, but avoids the symptoms
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants