-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Julia nightly throwing at jl_datatype_isinlinealloc
#41503
Comments
This has also made it into 1.7. |
So far I've managed to narrow it down to using ReverseDiff
exp_f(t) = 0
ReverseDiff.gradient(exp_f, [0.1]) |
Further reduced: struct a{d}
e::d
end
struct f{j,k} <: AbstractArray{a{f{Any,k}},Any}
l::j
end
f{Any,Any} |
I think that is #34223 actually. The presence of the type as part of its own supertype causes the order in which we need to compute the layout of the types to diverge from the order in which we need to allocate the (super)types, which makes this complicated. We might end up needing to prohibit a type like this from being inlineable ever to avoid that ordering problem. I'll see if I can put that in a PR. |
We hit what appears to be a very similar issue, but with a slightly different stacktrace:
Reverting 7ffc10b resolves the issue, but #41516 doesn't seem to do the trick. |
(Reopening to continue tracking the immediately preceding form of the issue.) |
According to #41516 (comment), can be triggered by testing DFTK. |
Confirmed,
|
In working towards an MRE or trace that I can hand off for the variant of this issue that our test suite hits, I managed to reproduce our variant locally and found that the stracktrace looks more similar to those posted above than seemed the case in our CI logs. In case it's useful while I continue working at this:
|
Okay thanks, here's another MWE for this issue (we fail to realize that this object is a concrete data type, should be in the cache, and should be given a layout):
Note that previously we were constructing a bad layout here (this is v1.6):
|
We are also hitting this in Oscar.jl, see oscar-system/Oscar.jl#587 |
Unfortunately the fix doesn't fix the issue for us. See a recent CI run here : https://github.com/JuliaMolSim/DFTK.jl/pull/522/checks?check_run_id=3421567794#step:7:458 and can be reproduced just by testing the DFTK package (tested on a nightly from today) |
(Reopening in accord with Antoine's comment. Testing #41935 on our codebase now as well, will report back.) |
MWE: struct Model{T}
atoms::Vector{Pair{Any, Vector{T}}}
end
compute_forces() = Model[][1].atoms[1][2]
precompile(compute_forces, ())
Model{Float64}([]) |
Can confirm fixed. Thanks! |
Need to compute `cacheable` after normalization, since the purpose of the normalization was to turn these into normal cacheable objects, when applicable. Brokenness exposed by JuliaLang#36211 Fixes JuliaLang#41503
Need to compute `cacheable` after normalization, since the purpose of the normalization was to turn these into normal cacheable objects, when applicable. Brokenness exposed by JuliaLang#36211 Fixes JuliaLang#41503
A recent version of Julia nightly started throwing errors on tests in Manifolds.jl, see for example these CI runs: https://github.com/JuliaManifolds/Manifolds.jl/pull/381/checks?check_run_id=3010181089 . On Windows, for example, a part of the error reads:
and on Ubuntu:
I'll try making an MWE.
The text was updated successfully, but these errors were encountered: