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

Assertion failure in type system #22592

Closed
simonster opened this issue Jun 28, 2017 · 5 comments
Closed

Assertion failure in type system #22592

simonster opened this issue Jun 28, 2017 · 5 comments
Assignees
Labels
domain:types and dispatch Types, subtyping and method dispatch kind:bug Indicates an unexpected problem or unintended behavior

Comments

@simonster
Copy link
Member

On JuliaIO/JLD2.jl@dfca1f0 (current JLD2 master) with 0.6 debug build:

  | | |_| | | | (_| |  |  Version 0.6.1-pre.0 (2017-06-19 13:06 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit dcf39a1 (8 days old release-0.6)
|__/                   |  x86_64-apple-darwin16.5.0

julia> using JLD2
Assertion failed: (!jl_subtype((jl_value_t*)sig, (jl_value_t*)type)), function check_ambiguous_visitor, file /usr/local/julia-release-0.6/src/gf.c, line 1129.

signal (6): Abort trap: 6
while loading /Users/simon/.julia/v0.6/JLD2/src/data.jl, in expression starting on line 914
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 3993141 (Pool: 3991608; Big: 1533); GC: 7
fish: 'julia-debug' terminated by signal SIGABRT (Abort)

The assertion failure occurs when loading this line. Appears to operate properly with a non-debug build.

@simonster simonster added the domain:types and dispatch Types, subtyping and method dispatch label Jun 28, 2017
@simonster
Copy link
Member Author

Minimal reproducer:

f(::UnionAll) = nothing
f(::DataType) = nothing
f{T<:DataType}(::Type{T}) = nothing

@simonster simonster added the kind:bug Indicates an unexpected problem or unintended behavior label Jul 9, 2017
simonster added a commit to JuliaIO/JLD2.jl that referenced this issue Jul 9, 2017
simonster added a commit to JuliaIO/JLD2.jl that referenced this issue Jul 9, 2017
@JeffBezanson
Copy link
Sponsor Member

Seems to be fixed on master? @simonster could you confirm whether JLD2 works?

@timholy
Copy link
Sponsor Member

timholy commented Dec 16, 2017

On a debug build of current master, here's a case that triggers the same assertion:

module CVS

abstract type Colorant{T,N} end
abstract type Color{T, N} <: Colorant{T,N} end
abstract type AbstractRGB{T} <: Color{T,3} end

AbstractGray{T} = Color{T,1}

MathTypes{T,C} = Union{AbstractRGB{T},AbstractGray{T}}

plus(a::AbstractGray, b::AbstractGray) = 1
plus(c::AbstractGray) = c
plus(a::MathTypes, b::MathTypes) = plus(promote(a, b)...)

end

It's a stripped-down version of ColorVectorSpace.

@timholy
Copy link
Sponsor Member

timholy commented Dec 16, 2017

It seems to be a problem of type specificity between the unary variant and the binary MathTypes variant:

julia: /home/tim/src/julia-1.0/src/gf.c:1152: check_ambiguous_visitor: Assertion `!jl_subtype((jl_value_t*)sig, (jl_value_t*)type)' failed.

Thread 1 "julia" received signal SIGABRT, Aborted.
0x00007ffff6b1e428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) f 4
#4  0x00007ffff7519df2 in check_ambiguous_visitor (oldentry=0x7fffea3562c0, closure0=0x7fffffffb890) at /home/tim/src/julia-1.0/src/gf.c:1152
1152            assert(!jl_subtype((jl_value_t*)sig, (jl_value_t*)type));
(gdb) call jl_type_morespecific(type, sig)
$1 = 0
(gdb) call jl_type_morespecific(sig, type)
$2 = 1
(gdb) call jl_(closure->newentry)
TypeMapEntry(sig=Tuple{typeof(CVS.plus), Union{CVS.AbstractRGB{T}, CVS.Color{T, 1}} where T, Union{CVS.AbstractRGB{T}, CVS.Color{T, 1}} where T}, simplesig=nothing, guardsigs=svec(), min_world=24860, max_world=-1, func=CVS.plus(...), isleafsig=false, issimplesig=false, va=false, next=↩︎
  TypeMapEntry(sig=Tuple{typeof(CVS.plus), CVS.Color{T, 1} where T}, simplesig=nothing, guardsigs=svec(), min_world=24859, max_world=-1, func=CVS.plus(...), isleafsig=false, issimplesig=false, va=false, next=↩︎
  TypeMapEntry(sig=Tuple{typeof(CVS.plus), CVS.Color{T, 1} where T, CVS.Color{T, 1} where T}, simplesig=nothing, guardsigs=svec(), min_world=24858, max_world=-1, func=CVS.plus(...), isleafsig=false, issimplesig=false, va=false, next=↩︎
  nothing)))
(gdb) call jl_(closure->newentry->next->sig)
Tuple{typeof(CVS.plus), CVS.Color{T, 1} where T}
(gdb) call jl_(type)
Tuple{typeof(CVS.plus), Union{CVS.AbstractRGB{T}, CVS.Color{T, 1}} where T, Union{CVS.AbstractRGB{T}, CVS.Color{T, 1}} where T}
(gdb) call jl_type_morespecific(type, closure->newentry->next->sig)
$3 = 1

So it seems that the method table is being sorted like this (in order of "most specific to least specific"):

plus(a::MathTypes, b::MathTypes) = plus(promote(a, b)...)
plus(c::AbstractGray) = c
plus(a::AbstractGray, b::AbstractGray) = 1

As evidence that this is correct, all I have to do is change the order of their definition to

plus(a::AbstractGray, b::AbstractGray) = 1
plus(a::MathTypes, b::MathTypes) = plus(promote(a, b)...)
plus(c::AbstractGray) = c

and then I don't trigger the assertion anymore, and the method table is

julia> methods(CVS.plus)
# 3 methods for generic function "plus":
[1] plus(c::Main.CVS.Color{T,1} where T) in Main.CVS at /tmp/CVS.jl:13
[2] plus(a::Main.CVS.Color{T,1} where T, b::Main.CVS.Color{T,1} where T) in Main.CVS at /tmp/CVS.jl:11
[3] plus(a::Union{Main.CVS.AbstractRGB{T}, Main.CVS.Color{T,1}} where T, b::Union{Main.CVS.AbstractRGB{T}, Main.CVS.Color{T,1}} where T) in Main.CVS at /tmp/CVS.jl:12

@JeffBezanson JeffBezanson self-assigned this Sep 11, 2018
@JeffBezanson JeffBezanson added this to the 1.0.x milestone Sep 11, 2018
JeffBezanson added a commit that referenced this issue Sep 11, 2018
We considered Union{A,B} more specific than B if A was more specific
than B (but not a subtype of it). Clearly, it should not be.
@JeffBezanson
Copy link
Sponsor Member

I believe this was fixed a while ago; @simonster please reopen if you're still able to reproduce this. The ColorVectorSpace issue is separate, #29136.

JeffBezanson added a commit that referenced this issue Sep 12, 2018
We considered Union{A,B} more specific than B if A was more specific
than B (but not a subtype of it). Clearly, it should not be.
JeffBezanson added a commit that referenced this issue Sep 13, 2018
We considered Union{A,B} more specific than B if A was more specific
than B (but not a subtype of it). Clearly, it should not be.
KristofferC pushed a commit that referenced this issue Sep 17, 2018
We considered Union{A,B} more specific than B if A was more specific
than B (but not a subtype of it). Clearly, it should not be.

(cherry picked from commit 3143d89)
KristofferC pushed a commit that referenced this issue Feb 11, 2019
We considered Union{A,B} more specific than B if A was more specific
than B (but not a subtype of it). Clearly, it should not be.

(cherry picked from commit 3143d89)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:types and dispatch Types, subtyping and method dispatch kind:bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants