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

Illegal instruction, not sure how it occurs, rr report included #38312

Closed
bhalonen opened this issue Nov 5, 2020 · 8 comments
Closed

Illegal instruction, not sure how it occurs, rr report included #38312

bhalonen opened this issue Nov 5, 2020 · 8 comments
Assignees
@vtjnash
Labels
bug Indicates an unexpected problem or unintended behavior compiler:precompilation Precompilation of modules rr trace included types and dispatch Types, subtyping and method dispatch

Comments

@bhalonen
Copy link

bhalonen commented Nov 5, 2020

https://s3.amazonaws.com/julialang-dumps/reports/2020-11-05T14-56-56-bhalonen.tar.zst

This is for last nights build, though it happens on 1.5.2 and 1.5.1 as well.

signal (4): Illegal instruction
in expression starting at /home/brenthalonen/projects/coho-deploy/CohoSim.jl/test/acmt.jl:1
getproperty at ./Base.jl:33 [inlined]
rehash! at ./dict.jl:178
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2191 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2373
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1693 [inlined]
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:115
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:204
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:434
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:489
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:489
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:669
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:879
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:827
jl_toplevel_eval_in at /buildworker/worker/package_linux64/build/src/toplevel.c:931
eval at ./boot.jl:360 [inlined]
include_string at ./loading.jl:1082

julia> versioninfo()
Julia Version 1.6.0-DEV.1426
Commit b00802bc5f (2020-11-04 22:35 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.0 (ORCJIT, skylake)
@bhalonen
Copy link
Author

bhalonen commented Nov 5, 2020

Put a few hours into extracting a mwe but gave up.

@bhalonen
Copy link
Author

bhalonen commented Nov 5, 2020

There is a struct with a union over missing involved might be similar to #38224

@bhalonen
Copy link
Author

bhalonen commented Nov 5, 2020

the bug does not occur in 1.3, additional info

@yuyichao yuyichao changed the title Segfault, not sure how it occurs, rr report included Illegal instruction, not sure how it occurs, rr report included Nov 5, 2020
@Keno
Copy link
Member

Keno commented Nov 7, 2020

Looks like the issue is a concrete type that doesn't get interned:

(rr) p jl_(0x7fb3a86e9cf0)
Array{Intervals.Interval{var"#s13", L, R} where R<:Intervals.Bound where L<:Intervals.Bound where var"#s13"<:(Union{Unitful.Quantity{T, Unitful.Dimensions{(Unitful.Dimension{:Time}(power=Base.Rational{Int64}(num=1, den=1)),)}(), U}, Unitful.Level{L, S, Unitful.Quantity{T, Unitful.Dimensions{(Unitful.Dimension{:Time}(power=Base.Rational{Int64}(num=1, den=1)),)}(), U}} where S where L} where U where T), 1}
$58 = void
(rr) p jl_(0x7fb3a33fc550)
Array{Intervals.Interval{var"#s13", L, R} where R<:Intervals.Bound where L<:Intervals.Bound where var"#s13"<:(Union{Unitful.Quantity{T, Unitful.Dimensions{(Unitful.Dimension{:Time}(power=Base.Rational{Int64}(num=1, den=1)),)}(), U}, Unitful.Level{L, S, Unitful.Quantity{T, Unitful.Dimensions{(Unitful.Dimension{:Time}(power=Base.Rational{Int64}(num=1, den=1)),)}(), U}} where S where L} where U where T), 1}

Codegen gets very unhappy as a result.

@Keno Keno added bug Indicates an unexpected problem or unintended behavior types and dispatch Types, subtyping and method dispatch labels Nov 7, 2020
@Keno Keno mentioned this issue Nov 7, 2020
Closed
@Keno
Copy link
Member

Keno commented Nov 7, 2020

Alright, both these types were deserialized from (different) .ji files. @JeffBezanson @vtjnash how is uniqueing of concrete types supposed to work for datatypes deserialized from .ji files.

@Keno Keno added the compiler:precompilation Precompilation of modules label Nov 7, 2020
@Keno
Copy link
Member

Keno commented Nov 7, 2020

MWE:

# Issue #38312
let
    TheType = """Array{Ref{Val{1}}, 1}"""
    load_path = mktempdir()
    load_cache_path = mktempdir()
    try
        write(joinpath(load_path, "Foo38312.jl"),
            """
            module Foo38312

            const TheType = $TheType

            end
            """)
        write(joinpath(load_path, "Bar38312.jl"),
            """
            module Bar38312

            const TheType = $TheType

            end
            """)

        pushfirst!(LOAD_PATH, load_path)
        pushfirst!(DEPOT_PATH, load_cache_path)

        Base.compilecache(Base.PkgId("Foo38312"))
        Base.compilecache(Base.PkgId("Bar38312"))
        @test pointer_from_objref((@eval (using Foo38312; Foo38312)).TheType) ===
        pointer_from_objref((@eval (using Bar38312; Bar38312)).TheType)
    finally
        rm(load_path, recursive=true)
        rm(load_cache_path, recursive=true)
    end
end

@Keno
Copy link
Member

Keno commented Nov 7, 2020

Huh:

(rr) p jl_(tj)
Ref{Base.Val{1}}
$104 = void
(rr) p jl_(kj)
Ref{Base.Val{1}}
$105 = void
(rr) p jl_types_equal(tj, kj)
$106 = 0

Keno added a commit that referenced this issue Nov 7, 2020
@Keno
Fix #38312 - Ordering error in .ji deserialization
143938d 
This issue is caused by deserializing types like RefValue{Ref{Val{1}}},
(i.e. Concrete{Abstract{Concrete{...}}}). What happened here is that
we were recaching the outer concrete type before the inner one. However,
our caching logic (and subtyping) assumes that it is only ever called
with completely recached parameter types, causing an incorrect cache
miss for the second deserialization. Fix that by not pushing the outer
type onto the flagref list until we've deserialized the inner type,
thus assuring that we've finished recaching the inner type before
attempting to recache the outer type.
@Keno
Copy link
Member

Keno commented Nov 7, 2020

Proposed fix in #38339 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vtjnash vtjnash

Labels
bug Indicates an unexpected problem or unintended behavior compiler:precompilation Precompilation of modules rr trace included types and dispatch Types, subtyping and method dispatch
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@vtjnash @KristofferC @Keno @bhalonen