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 !ijl_types_equal(mi->specTypes, type) fails when testing FourierFlows #50455

Closed
KristofferC opened this issue Jul 7, 2023 · 5 comments
Assignees
Labels
compiler:codegen Generation of LLVM IR and native code regression Regression in behavior compared to a previous version
Milestone

Comments

@KristofferC
Copy link
Member

When testing FourierFlows the following assertion is hit:

julia: /source/src/gf.c:221: jl_specializations_get_linfo_: Assertion `!ijl_types_equal(mi->specTypes, type)' failed.

[57] signal (6.-6): Aborted
in expression starting at /home/pkgeval/.julia/packages/FourierFlows/WMSMN/test/runtests.jl:41
gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x7f2e3ac1440e)
__assert_fail at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
jl_specializations_get_linfo_ at /source/src/gf.c:221
#specialize_method#289 at ./compiler/utilities.jl:226 [inlined]
specialize_method at ./compiler/utilities.jl:214 [inlined]
typeinf_edge at ./compiler/typeinfer.jl:871
abstract_call_method at ./compiler/abstractinterpretation.jl:629
abstract_call_gf_by_type at ./compiler/abstractinterpretation.jl:95
abstract_call_known at ./compiler/abstractinterpretation.jl:2052
abstract_call at ./compiler/abstractinterpretation.jl:2134
abstract_call at ./compiler/abstractinterpretation.jl:2127
...

PkgEval log: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/c9a32f4_vs_e4ee485/FourierFlows.primary.log

@KristofferC KristofferC added regression Regression in behavior compared to a previous version compiler:codegen Generation of LLVM IR and native code labels Jul 7, 2023
@KristofferC KristofferC added this to the 1.10 milestone Jul 7, 2023
@inkydragon
Copy link
Member

inkydragon commented Jul 11, 2023

A short test code. It could be further simplified.

  • test with Version 1.10.0-alpha1
using FourierFlows
using FourierFlows.FFTW


# include("test/test_grid.jl")
function test_plan_flows_fftrfft(::CPU; T=Float64)
    A = device_array(CPU())
    return typeof(FourierFlows.plan_flows_fft(A(rand(Complex{T}, (4,))))) <: FFTW.cFFTWPlan{Complex{T},-1,false,1} &&
            FourierFlows.plan_flows_rfft(A(rand(T, (4, 6, 8))), [1, 2]).region == [1, 2]
end

"This func contains many errors!"
function bad_function(g::ThreeDGrid)
    rand() > 0 || error("[bad_function] in func")
    ret1 = complex_func(g)
    ret2 = complex_func2(ret1)
    ret3 = complex_func3(ret2)
    return __undef_var__
end

# include("test/test_ifft.jl")
function test_irfft_cosmxcosny(g::ThreeDGrid)
    @show "[test_irfft_cosmxcosny] in func"
    bad = bad_function(g)
    irfft(bad, g.nx)
end

dev = CPU();
nx, ny, nz = 2, 2, 2;
Lx, Ly, Lz = 0, 0, 0;
g3 = ThreeDGrid(dev; nx, Lx, ny, Ly, nz, Lz);

@show "test_plan_flows_fftrfft"
test_plan_flows_fftrfft(dev)  # nedd this call

@show "--> test_irfft_cosmxcosny"
test_irfft_cosmxcosny(g3)
# if you run `test_irfft_cosmxcosny` before `test_plan_flows_fftrfft`
#   You will got: "ERROR: UndefVarError"

@maleadt
Copy link
Member

maleadt commented Jul 11, 2023

I'm looking into reducing/bisecting this.

@maleadt
Copy link
Member

maleadt commented Jul 12, 2023

Partially reduced to:

using CUDA, FFTW

plan_flows_rfft(argskwargs) = plan_rfft
plan_flows_rfft(a::CuArray, args... ) = plan_rfft(a, args... )
function ThreeDGrid(dev; nx, Lx, ny, Ly, nz)
    dev(dev)
end
device_array(CPU) = Array
function test_plan_flows_fftrfft( T)
  A = device_array(0)
  typeof(plan_flows_rfft(A(rand(T, 0)))) <: FFTW.rFFTWPlan &&
    plan_flows_rfft(A0, [])
end
dev = function (:)
  irfft(deepcopy0, gnx)
end
test_plan_flows_fftrfft(dev)
nx, ny, nz = 2, 0, 6
Lx, Ly= π, 4.0
ThreeDGrid(dev; nx, Lx, ny, Ly, nz )

Bisected to #49189, which doesn't make much sense...

@maleadt
Copy link
Member

maleadt commented Jul 12, 2023

Further reduced:

struct HandleCache
    active_handles::Set{Pair{Tuple{Any,Int,Dims},Cint}}
    function HandleCache()
        new()
    end
end
function pop!(cache, key)
    push!(cache.active_handles, key => handle)
end
struct CuArray
    dims::Dims
end
size(x::CuArray) = x.dims
const idle_handles = HandleCache()
function cufftGetPlan(args...)
    pop!(idle_handles, (ctx, args...))
end
function plan_brfft()
  cufftGetPlan(1, (size(X)...,))
end
plan_brfft()

This also bisects to a better culprit: #49017 (cc @vtjnash).

@vtjnash
Copy link
Member

vtjnash commented Aug 15, 2023

Further reduces to this set of facts, where we end up confused about there an NTuple is supposed to end up in the hash table:

julia> A = Val{Tuple{Vararg{Int}}}
Val{Tuple{Vararg{Int64}}}

julia> B = Val{Tuple{Vararg{Int64,N}} where N}
Val{Tuple{Vararg{Int64, N}} where N}

julia> A == B
false

julia> A <: B && B <: A
true

julia> A = Val{Tuple{Vararg{Int}}}
Val{Tuple{Vararg{Int64}}}

julia> B = Val{Tuple{Vararg{Int64,N}} where N}
Val{Tuple{Vararg{Int64, N}} where N}

julia> A.hash
-56068198

julia> B.hash
-545448230

julia> Tuple{Vararg{Int64}}.hash
1495893083

julia> (Tuple{Vararg{Int64,N}} where N).body.hash
0

KristofferC pushed a commit that referenced this issue Aug 23, 2023
Fixes #50455

(cherry picked from commit c239e99)
nalimilan pushed a commit that referenced this issue Nov 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:codegen Generation of LLVM IR and native code regression Regression in behavior compared to a previous version
Projects
None yet
Development

No branches or pull requests

4 participants