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

Type inference error on CI #38999

Closed
Keno opened this issue Dec 25, 2020 · 2 comments · Fixed by #39140
Closed

Type inference error on CI #38999

Keno opened this issue Dec 25, 2020 · 2 comments · Fixed by #39140
Labels
ci Continuous integration

Comments

@Keno
Copy link
Member

Keno commented Dec 25, 2020

Seems intermittent and does not cause the build to fail, but looks like this:

      From worker 7:	Internal error: encountered unexpected error in runtime:
      From worker 7:	TypeError(func=:typeassert, context="", expected=DataType, got=Union{})
      From worker 7:	jl_type_error_rt at /buildworker/worker/package_linux64/build/src/rtutils.c:119
      From worker 7:	jl_type_error at /buildworker/worker/package_linux64/build/src/rtutils.c:127
      From worker 7:	abstract_call_gf_by_type at ./compiler/abstractinterpretation.jl:124
      From worker 7:	abstract_call_known at ./compiler/abstractinterpretation.jl:1015
      From worker 7:	abstract_call at ./compiler/abstractinterpretation.jl:1038
      From worker 7:	abstract_call at ./compiler/abstractinterpretation.jl:1022
      From worker 7:	abstract_eval_statement at ./compiler/abstractinterpretation.jl:1145
      From worker 7:	typeinf_local at ./compiler/abstractinterpretation.jl:1399
      From worker 7:	typeinf_nocycle at ./compiler/abstractinterpretation.jl:1455
      From worker 7:	_typeinf at ./compiler/typeinfer.jl:216
      From worker 7:	typeinf at ./compiler/typeinfer.jl:211
      From worker 7:	typeinf_edge at ./compiler/typeinfer.jl:760
      From worker 7:	abstract_call_method at ./compiler/abstractinterpretation.jl:478
      From worker 7:	abstract_call_gf_by_type at ./compiler/abstractinterpretation.jl:141
      From worker 7:	abstract_call_known at ./compiler/abstractinterpretation.jl:1015
      From worker 7:	abstract_call at ./compiler/abstractinterpretation.jl:1038
      From worker 7:	abstract_call at ./compiler/abstractinterpretation.jl:1022
      From worker 7:	abstract_eval_statement at ./compiler/abstractinterpretation.jl:1145
      From worker 7:	typeinf_local at ./compiler/abstractinterpretation.jl:1399
      From worker 7:	typeinf_nocycle at ./compiler/abstractinterpretation.jl:1455
      From worker 7:	_typeinf at ./compiler/typeinfer.jl:216
      From worker 7:	typeinf at ./compiler/typeinfer.jl:211
      From worker 7:	typeinf_edge at ./compiler/typeinfer.jl:760
      From worker 7:	abstract_call_method at ./compiler/abstractinterpretat

https://build.julialang.org/#/builders/34/builds/7479/steps/5/logs/stdio
@Keno Keno added the ci Continuous integration label Dec 25, 2020
@Sacha0
Copy link
Member

Sacha0 commented Dec 25, 2020

We recently began seeing a somewhat similar failure on 1.7-dev:

Internal error: encountered unexpected error in runtime:
TypeError(func=:<:, context="", expected=Type, got=T<:Delve.REPL.Execution.Tracers.Tracer)
jl_type_error_rt at /buildworker/worker/package_linux64/build/src/rtutils.c:119
jl_type_error at /buildworker/worker/package_linux64/build/src/rtutils.c:127
jl_f_issubtype at /buildworker/worker/package_linux64/build/src/builtins.c:462
⊑ at ./compiler/typelattice.jl:184
tmerge at ./compiler/typelimits.jl:289
getfield_tfunc at ./compiler/tfuncs.jl:883
getfield_tfunc at ./compiler/tfuncs.jl:767
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2232 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2414
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1707 [inlined]
do_apply at /buildworker/worker/package_linux64/build/src/builtins.c:691
builtin_tfunction at ./compiler/tfuncs.jl:1555
abstract_call_builtin at ./compiler/abstractinterpretation.jl:806
jfptr_abstract_call_builtin_9720.clone_1 at /nix/store/6ddjfpb5gb3k80sfhy3h7sf10q5ivry8-julia-nightly-binary/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2232 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2414
abstract_call_known at ./compiler/abstractinterpretation.jl:936
abstract_call at ./compiler/abstractinterpretation.jl:1038
abstract_call at ./compiler/abstractinterpretation.jl:1022
abstract_eval_statement at ./compiler/abstractinterpretation.jl:1145
typeinf_local at ./compiler/abstractinterpretation.jl:1399
typeinf_nocycle at ./compiler/abstractinterpretation.jl:1455
_typeinf at ./compiler/typeinfer.jl:216
typeinf at ./compiler/typeinfer.jl:211
typeinf_edge at ./compiler/typeinfer.jl:760
abstract_call_method at ./compiler/abstractinterpretation.jl:478
abstract_call_gf_by_type at ./compiler/abstractinterpretation.jl:141
abstract_call_known at ./compiler/abstractinterpretation.jl:1015
abstract_call at ./compiler/abstractinterpretation.jl:1038
abstract_call at ./compiler/abstractinterpretation.jl:1022
abstract_eval_statement at ./compiler/abstractinterpretation.jl:1145
typeinf_local at ./compiler/abstractinterpretation.jl:1399
typeinf_nocycle at ./compiler/abstractinterpretation.jl:1455
_typeinf at ./compiler/typeinfer.jl:216
typeinf at ./compiler/typeinfer.jl:211
typeinf_edge at ./compiler/typeinfer.jl:760
abstract_call_method at ./compiler/abstractinterpretation.jl:478

This failure occurs when running the test suite of a private repo. Happy to provide more information via other channels if helpful as usual :).

@Sacha0 Sacha0 mentioned this issue Jan 4, 2021
Closed
@vtjnash
Copy link
Member

vtjnash commented Jan 7, 2021

MWE:

julia> Base._methods(convert, (Type{DataType}, Type{Union{}}), -1, Base.get_world_counter())
Any[]

julia> Base._methods(convert, (Type{DataType}, Type{Type{Type{Int}}}), -1, Base.get_world_counter())
1-element Vector{Any}:
 Core.MethodMatch(Tuple{typeof(convert), Type{DataType}, Type{Type{Type{Int64}}}}, svec(DataType), convert(::Type{T}, x::T) where T in Base at essentials.jl:205, true)

julia> Base._methods(convert, (Type{DataType}, Type{Union{}}), -1, Base.get_world_counter())
1-element Vector{Any}:
 Core.MethodMatch(Union{}, svec(), convert(::Type{T}, x::T) where T in Base at essentials.jl:205, true)

Which is because, per the code comment "TODO: this is probably solidly unsound and would corrupt the cache in many cases" :D

vtjnash added a commit that referenced this issue Jan 7, 2021
@vtjnash
gf: avoid adding cache entries wider than the original method
e165202 
Sometimes we want to widen the compilation signature, but then end up
with something which does not fit the original pattern. This then can
cause problems later, when we try to use the Method (from the cache),
but discover it does not actually match the call.

Fixes #38999
@vtjnash vtjnash mentioned this issue Jan 7, 2021
Merged
Keno pushed a commit that referenced this issue Jan 9, 2021
@vtjnash
gf: avoid adding cache entries wider than the original method (#39140)
8937f7e 
Sometimes we want to widen the compilation signature, but then end up
with something which does not fit the original pattern. This then can
cause problems later, when we try to use the Method (from the cache),
but discover it does not actually match the call.

Fixes #38999
KristofferC pushed a commit that referenced this issue Jan 9, 2021
@vtjnash @KristofferC
gf: avoid adding cache entries wider than the original method (#39140)
07a3c9e 
Sometimes we want to widen the compilation signature, but then end up
with something which does not fit the original pattern. This then can
cause problems later, when we try to use the Method (from the cache),
but discover it does not actually match the call.

Fixes #38999

(cherry picked from commit 8937f7e)
KristofferC pushed a commit that referenced this issue Feb 1, 2021
@vtjnash @KristofferC
gf: avoid adding cache entries wider than the original method (#39140)
39ecb93 
Sometimes we want to widen the compilation signature, but then end up
with something which does not fit the original pattern. This then can
cause problems later, when we try to use the Method (from the cache),
but discover it does not actually match the call.

Fixes #38999

(cherry picked from commit 8937f7e)
ElOceanografo pushed a commit to ElOceanografo/julia that referenced this issue May 4, 2021
@vtjnash @ElOceanografo
gf: avoid adding cache entries wider than the original method (JuliaL…
fb47da0 
…ang#39140)

Sometimes we want to widen the compilation signature, but then end up
with something which does not fit the original pattern. This then can
cause problems later, when we try to use the Method (from the cache),
but discover it does not actually match the call.

Fixes JuliaLang#38999
staticfloat pushed a commit that referenced this issue Dec 23, 2022
@vtjnash @staticfloat
gf: avoid adding cache entries wider than the original method (#39140)
b63e9de 
Sometimes we want to widen the compilation signature, but then end up
with something which does not fit the original pattern. This then can
cause problems later, when we try to use the Method (from the cache),
but discover it does not actually match the call.

Fixes #38999

(cherry picked from commit 8937f7e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ci Continuous integration
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

gf: avoid adding cache entries wider than the original method JuliaLang/julia
3 participants
@vtjnash @Keno @Sacha0