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.

Sign up for GitHub

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

Jump to bottom

segfault in GC when using cat() with ellipsis #9883

Closed
micklat opened this issue Jan 22, 2015 · 7 comments
Closed

segfault in GC when using cat() with ellipsis #9883

micklat opened this issue Jan 22, 2015 · 7 comments
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@micklat
Copy link
Contributor

micklat commented Jan 22, 2015

This program crashes:

cat(1, [zeros(1000) for i in 1:10000]...)

By contrast, this does not crash:

wanna_crash = false

n = 10000
k = 1000
parts = [zeros(Float64, k) for i in 1:n]
if wanna_crash
    x = cat(1, parts...)
else
    x = Array(Float64, n*k)
    for i in 1:n
        x[1+(i-1)*k : i*k] = parts[i]
    end
end
println("OK")

Crash backtrace for the one-liner:

signal (11): Segmentation fault
unknown function (ip: -419359242)
unknown function (ip: -419359852)
jl_gc_collect at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
allocobj at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
jl_alloc_array_1d at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
call at ./base.jl:256
cat_t at abstractarray.jl:750
jl_apply_generic at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
jl_f_apply at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
cat at abstractarray.jl:713
jl_apply_generic at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
jl_f_apply at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
anonymous at no file:0
unknown function (ip: -419382084)
unknown function (ip: -419379475)
jl_load at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
include at ./boot.jl:249
jl_apply_generic at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
include_from_node1 at loading.jl:128
jl_apply_generic at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
process_options at ./client.jl:319
_start at ./client.jl:403
jlcall__start_41786 at /usr/local/src/julia/usr/lib/julia/sys.so (unknown line)
jl_apply_generic at /usr/local/src/julia/usr/bin/../lib/libjulia.so (unknown line)
unknown function (ip: 4200165)
unknown function (ip: 4199114)
__libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 4199189)
unknown function (ip: 0)
Segmentation fault (core dumped)

Julia version:

Version 0.4.0-dev+2861 (2015-01-22 12:05 UTC)
Commit e726b6c (0 days old master)
x86_64-linux-gnu

This happens on a machine with 8Gb or RAM.
@micklat micklat changed the title segfault in GC when using ellipsis segfault in GC when using cat() with ellipsis Jan 22, 2015
@vtjnash vtjnash added the bug Indicates an unexpected problem or unintended behavior label Jan 23, 2015
@ivarne
Copy link
Member

ivarne commented Jan 23, 2015

It doesn't crash for me on OSX

Version 0.4.0-dev+2874 (2015-01-22 19:42 UTC)
Commit 180a6c5* (0 days old master)
x86_64-apple-darwin14.0.0

@dhoegh
Copy link
Contributor

dhoegh commented Jan 23, 2015

I can reproduce it on windows with the following versioninfo:

Julia Version 0.4.0-dev+2818
Commit 196544c (2015-01-19 18:50 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

Backtrace

           _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+2818 (2015-01-19 18:50 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 196544c (3 days old master)
|__/                   |  x86_64-w64-mingw32

julia> cat(1, [zeros(1000) for i in 1:10000]...)

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x6bfa8467 -- jl_profile_is_running at  (unknown line)
jl_profile_is_running at  (unknown line)
jl_profile_is_running at  (unknown line)
jl_profile_is_running at  (unknown line)
jl_gc_collect at  (unknown line)
allocobj at  (unknown line)
popmeta! at expr.jl:158
inline_worthy at inference.jl:2567
inlineable at inference.jl:2219
jl_apply_generic at  (unknown line)
inlining_pass at inference.jl:2723
inlining_pass at inference.jl:2657
jl_apply_generic at  (unknown line)
inlining_pass at inference.jl:2617
jl_apply_generic at  (unknown line)
typeinf at inference.jl:1597
jlcall_typeinf_9 at  (unknown line)
jl_apply_generic at  (unknown line)
typeinf_ext at inference.jl:1243
jl_apply_generic at  (unknown line)
jl_method_cache_insert at  (unknown line)
jl_method_cache_insert at  (unknown line)
jl_apply_generic at  (unknown line)
jl_f_apply at  (unknown line)
cat at abstractarray.jl:713
jl_apply_generic at  (unknown line)
jl_f_apply at  (unknown line)
anonymous at no file:0
jl_eval_with_compiler_p at  (unknown line)
jl_toplevel_eval_in at  (unknown line)
eval_user_input at REPL.jl:54
jlcall_eval_user_input_1165 at  (unknown line)
jl_apply_generic at  (unknown line)
anonymous at task.jl:83
jl_unprotect_stack at  (unknown line)
jl_unprotect_stack at  (unknown line)

@nalimilan
Copy link
Member

@micklat Could you show the full output of versioninfo()? In particular the CPU information might be interesting.

FWIW I don't see the crash here on Linux:

julia> versioninfo()
Julia Version 0.4.0-dev+2876
Commit f164ac1* (2015-01-22 22:58 UTC)
Platform Info:
  System: Linux (x86_64-redhat-linux)
  CPU: Intel(R) Core(TM) i5 CPU       M 450  @ 2.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

@micklat
Copy link
Contributor Author

micklat commented Jan 23, 2015

versioninfo()
Julia Version 0.4.0-dev+2861
Commit e726b6c (2015-01-22 12:05 UTC)
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3

Perhaps it is worth noting that replacing "cat(1," with "vcat(" avoids the crash.

@quinnj
Copy link
Member

quinnj commented Jan 23, 2015

I don't see it on OSX commit 8b4e9e9, or windows 64-bit commit e5b4e0b

@JeffBezanson
Copy link
Member

Managed to catch it in valgrind:

==6247== Conditional jump or move depends on uninitialised value(s)
==6247==    at 0x4FA208A: gc_mark_stack (gc.c:653)
==6247==    by 0x4FA208A: gc_mark_task (gc.c:712)
==6247==    by 0x4FA2C4C: gc_mark (gc.c:847)
==6247==    by 0x4FA2C4C: jl_gc_collect (gc.c:962)
==6247==    by 0x4FA3AB4: pool_alloc (gc.c:502)
==6247==    by 0x4FA3AB4: allocobj (gc.c:1038)
==6247==    by 0x4F939A4: _new_array_ (array.c:80)
==6247==    by 0x4F939A4: _new_array (array.c:134)
==6247==    by 0x4F939A4: jl_alloc_array_1d (array.c:308)
==6247==    by 0x7D4980D: julia_call_26168 (in /home/jeff/src/julia2/julia/usr/lib/julia/sys.so)
==6247==    by 0x8DECD6F: ???
==6247==    by 0x4F3EED4: jl_apply (julia.h:1014)
==6247==    by 0x4F3EED4: jl_apply_generic (gf.c:1643)
==6247==    by 0x4F45B28: jl_apply (julia.h:1014)
==6247==    by 0x4F45B28: jl_f_apply (builtins.c:457)
==6247==    by 0x8DEC757: ???
==6247==    by 0x4F3EED4: jl_apply (julia.h:1014)
==6247==    by 0x4F3EED4: jl_apply_generic (gf.c:1643)
==6247==    by 0x4F45C83: jl_apply (julia.h:1014)
==6247==    by 0x4F45C83: jl_f_apply (builtins.c:428)
==6247==    by 0x8DEC404: ???

Consistent with a bad GC frame of some sort.

@JeffBezanson
Copy link
Member

Interesting: I get this consistently on 64-bit linux (gcc 4.9.1) built in release mode, and it goes away in debug mode.

vtjnash added a commit that referenced this issue Feb 8, 2015
@vtjnash
fix #9883, #10085
d780b7f 
apparently some compilers don't like my previous attempts to generate conditional alloca gcframes
@vtjnash vtjnash closed this as completed in f769e41 Feb 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@ivarne @vtjnash @JeffBezanson @nalimilan @quinnj @micklat @dhoegh