Unreachable reached at 0000000015349AF1 #25430
Comments
|
Thank you for the report. This resulted in a |
|
Oh sorry, forgot to include that: julia> versioninfo()
Julia Version 0.7.0-DEV.3234
Commit 2cc82d29e1* (2018-01-02 11:44 UTC)
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, skylake) |
|
It is reproducible yes. |
|
Works fine when I take the julia> struct FunctorArgTrait{T<:Tuple} end
julia> struct FunctorRetTrait{S} end
julia> f(x, y) = x+y
f (generic function with 1 method)
julia> get_ret_trait(::Type{typeof(f)}, input_types::Type{<:Tuple}) = FunctorRetTrait{promote_type(input_types.parameters...)}()
get_ret_trait (generic function with 1 method)
julia> get_arg_trait(::Type{typeof(f)}) = FunctorArgTrait{Tuple{Any,Any}}()
get_arg_trait (generic function with 1 method)
julia> g(f::F, x, y, ::FunctorArgTrait{Tuple{T1, T2}}, ::FunctorRetTrait{S}) where {F<:Function, S<:Int, T1 >: Int, T2 >: Int} = f(x,y)::S
g (generic function with 1 method)
julia> g(f::F, x, y) where {F<:Function} = g(f, x, y, get_arg_trait(F), get_ret_trait(F, Tuple{Int,Int}))
g (generic function with 2 methods)
julia> g(f, 1, 2)
3 |
|
AFAIK the two function signatures are different as |
|
There is something funny about dispatch/subtyping here. Reduced example: julia> f(t::Vector{Tuple{>:Int}}) where T = @assert t isa Vector{Tuple{>:Int}}
f (generic function with 1 method)
julia> f(Vector{Tuple{Any}}())
ERROR: AssertionError: t isa Vector{Tuple{>:Int}}
Stacktrace:
[1] f(::Array{Tuple{Any},1}) at ./REPL[1]:1
[2] top-level scopeThe assertion fails as julia> Vector{Tuple{Any}}() isa Vector{Tuple{>:Int}}
falsewhile the method is dispatched to because julia> typeof(Vector{Tuple{Any}}()) <: Vector{Tuple{>:Int}}
truewhere the latter looks bogus to me. |
|
After some more thought, Also julia> g(t::Vector{Tuple{>:Int}}) = @assert t isa Vector{Tuple{>:Int}} # no where {T} here
g (generic function with 1 method)
julia> g(Vector{Tuple{Any}}())
ERROR: MethodError: no method matching g(::Array{Tuple{Any},1})
Closest candidates are:
g(::Array{Tuple{#s1} where #s1>:Int64,1}) at REPL[23]:1then looks wrong. |
|
I think I've pinned down the problem here: The code in subtype.c assumes that concrete/leaf types are identical if they are type-equal. However, e.g. julia> T1, T2 = Vector{Tuple{>:Int}}, Vector{Tuple{Any}}
(Array{Tuple{#s1} where #s1>:Int64,1}, Array{Tuple{Any},1})
julia> T1 == T2
true
julia> T1 === T2
falseWhat trips off inference in the OPs example is that julia> typeintersect(T1, T2)
Union{}Simply removing the following lines resolves the problems reported in this issue: Lines 209 to 212 in 11dcd63 Lines 253 to 258 in 11dcd63 Lines 1210 to 1211 in 11dcd63 However, I'm a bit afraid that these constitute valuable fast paths and it would probably be beneficial to just limit them down a bit further instead of removing them altogether. I'm thinking of replacing the
The other option would be to ensure that leaf types are always normalized. I think this is what we've been trying to achieve. But I'm wondering whether that is achievable in general. As e.g. Any insights to share, @JeffBezanson? |
|
Excellent investigation, @martinholters ! The |
Yes, but we should definitely be able do that – there's a linear-scan cache in datatype instantiation for this purpose. (I've been trying to find an old commit where I had started working on this, but I'm pretty sure at this point that I've lost it and will need to recreate that). |
|
Ah, thanks for the pointer, @vtjnash! The problem here is that |
|
I've tried this: --- a/src/jltypes.c
+++ b/src/jltypes.c
@@ -725,6 +725,10 @@ static jl_value_t *lookup_type(jl_typename_t *tn, jl_value_t **key, size_t n)
JL_TIMING(TYPE_CACHE_LOOKUP);
int ord = is_typekey_ordered(key, n);
ssize_t idx = lookup_type_idx(tn, key, n, ord);
+ if (ord && idx < 0) { // also search in linear cache
+ ord = !ord;
+ idx = lookup_type_idx(tn, key, n, ord);
+ }
jl_value_t *t = (idx < 0) ? NULL : jl_svecref(ord ? tn->cache : tn->linearcache, idx);
return t;
}
@@ -802,6 +806,12 @@ jl_value_t *jl_cache_type_(jl_datatype_t *type)
type = (jl_datatype_t*)jl_svecref(ord ? type->name->cache : type->name->linearcache, idx);
else
cache_insert_type((jl_value_t*)type, ~idx, ord);
+ if (ord) { // also store in linear cache
+ ssize_t idx = lookup_type_idx(type->name, jl_svec_data(type->parameters),
+ jl_svec_len(type->parameters), 0);
+ if (idx < 0)
+ cache_insert_type((jl_value_t*)type, ~idx, 0);
+ }
}
return (jl_value_t*)type;
}And it solves this issue. Yay! But... It may of course lead to unexpected normalization: julia> Vector{Tuple{Any}}
Array{Tuple{#s2} where #s2>:Int64,1}because it just so happened that I had instantiated the latter first. Also Line 172 in 7d3991f results in a StackOverflowError. I had seen that before, though, when just disabling the fastpaths discussed above---maybe it is just accidentally working at the moment?
I tend to try the following:
Does that sound reasonable? |
|
I'm a bit confused by the ordered cache. Shouldn't the entries be mutually type-unequal? Because: julia> Vector{Vector{Tuple{Any}}} # this goes into the ordered cache
Array{Array{Tuple{Any},1},1}
julia> Vector{Vector{Tuple{>:Int}}} # this too - but should it?
Array{Array{Tuple{#s1} where #s1>:Int64,1},1}
julia> Vector.body.name.cache[203]
Array{Array{Tuple{Any},1},1}
julia> Vector.body.name.cache[204]
Array{Array{Tuple{#s1} where #s1>:Int64,1},1}
julia> Vector.body.name.cache[203] == Vector.body.name.cache[204]
trueShould |
I was running the following code, when Julia crashed and I got the following error:
The text was updated successfully, but these errors were encountered: