0.5: Illegal instruction 4 #17003
Labels
Milestone
Comments
|
Here's a non-crashing version of the inconsistency: dirichlet(Interval()^2)displays no output while @code_typed dirichlet(Interval()^2)shows that the return type is Array{ApproxFun.Operator{BandedMatrices.BandedMatrix{Float64}},1}) |
|
Nevermind, that is due to a questionable override of Base.writemime |
|
SIGILL is likely due to functions that returns unexpectedly. You could check |
|
I managed to trigger it with a shorter sequence in julia-debug by running the following in a .jl file (running on command prompt or deleting lines does not trigger the crash!): using ApproxFun
dx=dy=Interval()
d=dx*dy
x=Fun(identity,dx);y=Fun(identity,dy)
G=[real(exp(-1+1.0im*y));
real(exp(1+1im*y));
real(exp(x-1im));
real(exp(x+1im));0.];
A=[dirichlet(d);lap(d)]Here's the versioninfo: Julia Version 0.5.0-dev+4850
Commit 9ae4520 (2016-06-18 03:25 UTC)
DEBUG build
Platform Info:
System: Darwin (x86_64-apple-darwin15.5.0)
CPU: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz
WORD_SIZE: 64
BLAS: libgfortblas
LAPACK: liblapack
LIBM: libopenlibm
LLVM: libLLVM-3.7.1 (ORCJIT, ivybridge) |
|
This is still present in the latest build. I tried working around it by changing the offending line from a comprehension to an explicit constructed array, but the bug remained. |
|
The latest build gives a bit more information: apparently a call to while loading /Users/solver/.julia/v0.5/ApproxFun/test/PDETest.jl, in expression starting on line 16
copy! at ./abstractarray.jl:393
kron at /Users/solver/.julia/v0.5/ApproxFun/src/PDE/KroneckerOperator.jl:298
dirichlet at /Users/solver/.julia/v0.5/ApproxFun/src/PDE/PDE.jl:49
jl_call_method_internal at /Users/solver/Projects/julia5/src/./julia_internal.h:177 [inlined]
jl_apply_generic at /Users/solver/Projects/julia5/src/gf.c:2034
do_call at /Users/solver/Projects/julia5/src/interpreter.c:66
eval at /Users/solver/Projects/julia5/src/interpreter.c:190
do_call at /Users/solver/Projects/julia5/src/interpreter.c:65
eval at /Users/solver/Projects/julia5/src/interpreter.c:190
eval_body at /Users/solver/Projects/julia5/src/interpreter.c:469
jl_interpret_call at /Users/solver/Projects/julia5/src/interpreter.c:573
jl_toplevel_eval_flex at /Users/solver/Projects/julia5/src/toplevel.c:572
jl_parse_eval_all at /Users/solver/Projects/julia5/src/ast.c:717
jl_load at /Users/solver/Projects/julia5/src/toplevel.c:596 [inlined]
jl_load_ at /Users/solver/Projects/julia5/src/toplevel.c:605
include_from_node1 at ./loading.jl:426
jl_call_method_internal at /Users/solver/Projects/julia5/src/./julia_internal.h:177 [inlined]
jl_apply_generic at /Users/solver/Projects/julia5/src/gf.c:2034
do_call at /Users/solver/Projects/julia5/src/interpreter.c:66
eval at /Users/solver/Projects/julia5/src/interpreter.c:190
jl_toplevel_eval_flex at /Users/solver/Projects/julia5/src/toplevel.c:558
jl_parse_eval_all at /Users/solver/Projects/julia5/src/ast.c:717
jl_load at /Users/solver/Projects/julia5/src/toplevel.c:596 [inlined]
jl_load_ at /Users/solver/Projects/julia5/src/toplevel.c:605
include_from_node1 at ./loading.jl:426
jl_call_method_internal at /Users/solver/Projects/julia5/src/./julia_internal.h:177 [inlined]
jl_apply_generic at /Users/solver/Projects/julia5/src/gf.c:2034
process_options at ./client.jl:262
_start at ./client.jl:318
jl_call_method_internal at /Users/solver/Projects/julia5/src/./julia_internal.h:177 [inlined]
jl_apply_generic at /Users/solver/Projects/julia5/src/gf.c:2034
true_main at /Users/solver/Projects/julia5/usr/bin/julia (unknown line)
main at /Users/solver/Projects/julia5/usr/bin/julia (unknown line)
Allocations: 480657994 (Pool: 480586587; Big: 71407); GC: 913 |
|
Would this be a regression that we need to fix for 0.5? |
|
Yes, it’s fine in 0.4 and it was actually working fine in 0.5 a month ago or so.
|
|
See also my very early comment above #17003 (comment) if you are still seeing a sigill. |
|
I haven't been able to find @llvm.trap |
|
So what's the instruction it fails on in the debugger? |
|
I don't know how to use the debugger. |
|
OK I brew installed gdb, and tried running the script but get the error |
|
OK I got it working, here is what |
JeffBezanson
added
kind:bug
|
try with julia-debug? and maybe lldb might work better than gdb on mac |
|
|
|
OK this is what lldb gives: |
|
So it is a |
|
I tried calling it on |
|
The closest I've gotten to reducing the crash is to change Bx=dirichlet(d[1])
C=ConstantOperator{Float64,Float64}(1.0)
kron(Bx,C)Running |
|
It appears to be in copy!. You can find out which exactly by calling |
|
I don't know much about gdb (or lldb) so I'd need more instructions, in particular what "right frame" means. It would probably be better to do i tin lldb, since that seems to be giving more information. |
|
Run jameson's command when you see the sigill. |
|
I don’t think it worked out as intended: [New Thread 0x1563 of process 23879] Thread 1 received signal SIGILL, Illegal instruction.
|
|
lldb |
|
This was referenced Aug 16, 2016
Closed
Closed
|
A repro reduced from #18299 (it stack overflows instead of trap here but the reason is the same). #!/usr/bin/julia
abstract C{T,N}
type A{T,N} <: C{T,N}
v::T
end
typealias A1{T} C{T,1}
type B
x::A
end
function f(x::A1)
end
function f(x::A)
f(A(x))
end
function g(b::B)
v = b.x
f(v)
end
code_warntype(f, Tuple{A})
@code_warntype g(B(A{Int,1}(1)))
g(B(A{Int,1}(1)))Somehow the type inference think only the wider type can match and therefore thinks it is always recursing and never returns. (Might be dup of one of the type intersection issues) |
|
Actually the issue above is slightly different, there's a undetected ambiguity in the code above. The original code doesn't have the ambiguity so I still need to figure out the condition that triggers the original issue. |
|
OK, this time by actually directly reducing the code from #18299 instead of trying to construct from bottom up half way through..... abstract AArray{T,N}
typealias AVector{T} AArray{T,1}
immutable Nable{T}
end
immutable NArray{T,N} <: AArray{Nable{T},N}
end
(::Type{NArray}){T,N}(::Array{T,N}) = NArray{T,N}()
gl = [1, 2, 3]
f2(item::AVector) = nothing
f2(::Any) = f2(NArray(gl))
f2(1) |
|
this is similar to #18307 then? |
|
The ambiguity might be (the problem here seems that we always treat |
vtjnash
removed
status:priority
|
probably will be fixed by #18457? |
StefanKarpinski
added
status:help wanted
yuyichao
removed
the
status:help wanted
|
Seems fixed. |
yuyichao
changed the title
Merged
KristofferC
added a commit
that referenced
this issue
May 26, 2017
KristofferC
added a commit
that referenced
this issue
May 26, 2017
tkelman
pushed a commit
that referenced
this issue
Jun 3, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yet another ApproxFun segfault, that only appears when running all the tests (so hard to isolate).
There's some bizarre behaviour when running the line in question, but does not immediately cause the segfault. I'll try to narrow down the issue.
The text was updated successfully, but these errors were encountered: