julia type inference crashes (typeerror) #41908
Assignees
Labels
bug
Indicates an unexpected problem or unintended behavior
compiler:inference
Type inference
types and dispatch
Types, subtyping and method dispatch
Comments
|
Is there a tool that would allow me to debug this myself? I tried sprinkling in println's in some compiler/*.jl files but not only did compilation appear to hang, this will also take a really long time to get to the bottom off, with all that recompilation. |
|
Can you post the full stack trace? If I could see which line of base/compiler/*.jl was throwing the error, it could likely be fixed easily, and an example case generated, from knowing that |
|
|
this should have been the stack trace for julia master |
|
Heh, trying to find a simple reproducer I stumbled upon a different but likely similar issue: using LinearAlgebra
function foo()
x = Any[1][1]
x = x::(Diagonal{Int, T} where Int<:T<:Int)
size(x)
end
foo()Works (=only throws a runtime-error) on 1.6, but fails on 1.7 and master. Worth its own issue given that it is a regression? |
|
They are slightly different, but I think we can keep them both in this issue, since they make sense to fix together. original: julia> bar(x::Diagonal{Int, T}) where {Int<:T<:Int} = 1
julia> foo() = bar(Any[1][1])
julia> foo()
Internal error: encountered unexpected error in runtime:
TypeError(func=:Diagonal, context="V", expected=V<:AbstractArray{T, 1}, got=Int64)
jl_type_error_rt at /Users/jameson/julia1/src/rtutils.c:119
check_datatype_parameters at /Users/jameson/julia1/src/jltypes.c:1205
inst_datatype_inner at /Users/jameson/julia1/src/jltypes.c:1368
inst_type_w_ at /Users/jameson/julia1/src/jltypes.c:1760
inst_tuple_w_ at /Users/jameson/julia1/src/jltypes.c:1653
jl_instantiate_unionall at /Users/jameson/julia1/src/jltypes.c:1018 [inlined]
jl_apply_type at /Users/jameson/julia1/src/jltypes.c:972
subst_trivial_bounds at ./compiler/utilities.jl:159
normalize_typevars at ./compiler/utilities.jl:169
specialize_method at ./compiler/utilities.jl:181
specialize_method at ./compiler/utilities.jl:180 [inlined]
typeinf_edge at ./compiler/typeinfer.jl:780 [inlined]and yours I see as "works" on master too: julia> foo()
Internal error: encountered unexpected error in runtime:
TypeError(func=:Diagonal, context="V", expected=V<:AbstractArray{T, 1}, got=Int64)
jl_type_error_rt at /Users/jameson/julia1/src/rtutils.c:119
check_datatype_parameters at /Users/jameson/julia1/src/jltypes.c:1205
inst_datatype_inner at /Users/jameson/julia1/src/jltypes.c:1368
inst_type_w_ at /Users/jameson/julia1/src/jltypes.c:1760
jl_instantiate_unionall at /Users/jameson/julia1/src/jltypes.c:1018 [inlined]
normalize_unionalls at /Users/jameson/julia1/src/jltypes.c:1313
inst_datatype_inner at /Users/jameson/julia1/src/jltypes.c:1330
jl_apply_tuple_type_v_ at /Users/jameson/julia1/src/jltypes.c:1538 [inlined]
jl_apply_tuple_type_v at /Users/jameson/julia1/src/jltypes.c:1548
_jl_invoke at /Users/jameson/julia1/src/gf.c:0 [inlined]
jl_apply_generic at /Users/jameson/julia1/src/gf.c:2427
jl_apply at /Users/jameson/julia1/src/./julia.h:1768 [inlined]
do_apply at /Users/jameson/julia1/src/builtins.c:713
argtypes_to_type at ./compiler/typeutils.jl:53 [inlined] |
vtjnash
added
bug
|
Looks like the OP can pragmatically be solved with diff --git a/base/compiler/utilities.jl b/base/compiler/utilities.jl
index 5d4d52172a..852ec1e216 100644
--- a/base/compiler/utilities.jl
+++ b/base/compiler/utilities.jl
@@ -166,7 +166,11 @@ end
# f(x::S) where S<:Int
# gets cached and matches a concrete dispatch case.
function normalize_typevars(method::Method, @nospecialize(atypes), sparams::SimpleVector)
- at2 = subst_trivial_bounds(atypes)
+ try
+ at2 = subst_trivial_bounds(atypes)
+ catch
+ return atypes, sparams
+ end
if at2 !== atypes && at2 == atypes
atypes = at2
sp_ = ccall(:jl_type_intersection_with_env, Any, (Any, Any), at2, method.sig)::SimpleVector(Is there a nice way of finding out whether The other case is slightly trickier as julia> Tuple{LinearAlgebra.Diagonal{Int64, T} where Int64<:T<:Int64}
ERROR: TypeError: in Diagonal, in V, expected V<:AbstractArray{T, 1}, got Type{Int64}I guess we would want to actually form that type? (Alternatively, maybe we should forbid |
|
Ah, I already needed that patch in #41795. |
JeffBezanson
added a commit
that referenced
this issue
Aug 23, 2021
JeffBezanson
added a commit
that referenced
this issue
Aug 25, 2021
KristofferC
pushed a commit
that referenced
this issue
Aug 25, 2021
63 tasks
KristofferC
pushed a commit
that referenced
this issue
Oct 29, 2021
KristofferC
pushed a commit
that referenced
this issue
Nov 11, 2021
LilithHafner
pushed a commit
to LilithHafner/julia
that referenced
this issue
Feb 22, 2022
…ng#41976) Co-authored-by: Martin Holters <martin.holters@hsu-hh.de>
LilithHafner
pushed a commit
to LilithHafner/julia
that referenced
this issue
Mar 8, 2022
…ng#41976) Co-authored-by: Martin Holters <martin.holters@hsu-hh.de>
staticfloat
pushed a commit
that referenced
this issue
Dec 23, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
my tests started crashing with the stacktrace:
happens at least on julia 1.6.2, and also on master.
I wasn't able to really reduce it down very far, as it's a reasonably large codebase. To run it, you need my fork of TensorKit.jl, and the planocalypse branch of MPSKit.jl . I will try to reduce it down further, but so far I didn't have much luck.
The text was updated successfully, but these errors were encountered: