-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
Failed to precompile #136
Comments
What's the rest of the information for reproducing it? |
julia> versioninfo()
Julia Version 1.8.1
Commit afb6c60d69a (2022-09-06 15:09 UTC)
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 4 × Common KVM processor
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-13.0.1 (ORCJIT, nocona)
Threads: 1 on 4 virtual cores |
What about on 1.8.5? What's the error message? |
julia> import NonlinearSolve
[ Info: Precompiling NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec]
ERROR: Failed to precompile NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec] to /usr/share/julia/compiled/v1.8/NonlinearSolve/jl_SNb1wF.
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:35
[2] compilecache(pkg::Base.PkgId, path::String, internal_stderr::IO, internal_stdout::IO, keep_loaded_modules::Bool)
@ Base ./loading.jl:1705
[3] compilecache
@ ./loading.jl:1649 [inlined]
[4] _require(pkg::Base.PkgId)
@ Base ./loading.jl:1337
[5] _require_prelocked(uuidkey::Base.PkgId)
@ Base ./loading.jl:1200
[6] macro expansion
@ ./loading.jl:1180 [inlined]
[7] macro expansion
@ ./lock.jl:223 [inlined]
[8] require(into::Module, mod::Symbol)
@ Base ./loading.jl:1144 |
On 1.8.5? |
Sry, I don't have that installed right now. |
Can you try it? As a patch release it has bugfixes to Base and the compiler. |
I had a similar issue but without an error since it would close the terminal completely when I tried to precompile |
It also happens with Julia v1.7.3 (the latest release of v1.7, which we use for CI with Trixi.jl): julia> using Pkg; Pkg.activate(temp=true); Pkg.add("NonlinearSolve"); Pkg.precompile()
Activating new project at `/tmp/jl_jbRKDZ`
Updating registry at `~/.julia/registries/General.toml`
Resolving package versions...
Updating `/tmp/jl_jbRKDZ/Project.toml`
[8913a72c] + NonlinearSolve v1.2.0
[...]
Precompiling project...
✗ NonlinearSolve
23 dependencies successfully precompiled in 85 seconds (92 already precompiled)
1 dependency errored. To see a full report either run `import Pkg; Pkg.precompile()` or load the package
Precompiling project...
✗ NonlinearSolve
0 dependencies successfully precompiled in 31 seconds (115 already precompiled)
ERROR: The following 1 direct dependency failed to precompile:
NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec]
Failed to precompile NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec] to ~/.julia/compiled/v1.7/NonlinearSolve/jl_O7Z7W1.
Stacktrace:
[1] pkgerror(msg::String)
@ Pkg.Types ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/Types.jl:68
[2] precompile(ctx::Pkg.Types.Context; internal_call::Bool, strict::Bool, warn_loaded::Bool, already_instantiated::Bool, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
@ Pkg.API ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1362
[3] precompile
@ ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1013 [inlined]
[4] #precompile#220
@ ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1011 [inlined]
[5] precompile()
@ Pkg.API ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1011
[6] top-level scope
@ REPL[1]:1 |
Interesting, it doesn't give an error message? What happens if you It sounds like it's something that was fixed in later versions of Julia so I'll have to boot up v1.7.3 to reproduce. But that has a big startup time on my current laptop and I'm currently at a hackathon (and as described in https://discourse.julialang.org/t/julia-1-9-beta3-is-much-slower-for-first-time-users/93429/24 this laptop is not for programming haha) so if someone could post the error message I can try a few things. Or if someone could just try removing something from the snoop precompilation and see if that fixes it that could be good. |
Continuing the post above with the output on Julia v1.7.3: Failed to precompile NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec] to ~/.julia/compiled/v1.7/NonlinearSolve/jl_TvjAdN.
Stacktrace:
[1] pkgerror(msg::String)
@ Pkg.Types ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/Types.jl:68
[2] precompile(ctx::Pkg.Types.Context; internal_call::Bool, strict::Bool, warn_loaded::Bool, already_instantiated::Bool, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
@ Pkg.API ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1362
[3] precompile
@ ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1013 [inlined]
[4] #precompile#220
@ ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1011 [inlined]
[5] precompile()
@ Pkg.API ~/Software/julia-1.7.3/share/julia/stdlib/v1.7/Pkg/src/API.jl:1011
[6] top-level scope
@ REPL[1]:1
julia> using NonlinearSolve
[ Info: Precompiling NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec]
ERROR: Failed to precompile NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec] to ~/.julia/compiled/v1.7/NonlinearSolve/jl_mVZo9L.
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:33
[2] compilecache(pkg::Base.PkgId, path::String, internal_stderr::IO, internal_stdout::IO, ignore_loaded_modules::Bool)
@ Base ./loading.jl:1466
[3] compilecache(pkg::Base.PkgId, path::String)
@ Base ./loading.jl:1410
[4] _require(pkg::Base.PkgId)
@ Base ./loading.jl:1120
[5] require(uuidkey::Base.PkgId)
@ Base ./loading.jl:1013
[6] require(into::Module, mod::Symbol)
@ Base ./loading.jl:997 It comes with a huge increase of RAM usage - so much that it starts swapping, slows down everything considerably, and nearly runs out of space... |
Try removing TrustRegion from precompilation. Something seems bugged with its precompilation with Float32 (that's being fixed in the other PR) |
Seems to be fixed already on |
Okay that makes sense, no wonder I was having trouble reproducing. If someone could just do this last step (#132 (comment)) then we should tag all of the Float32 type fixes. |
We see something that could be OOM errors on GH Actions Windows machines, which would be consistent with your observation. |
This should be fixed with the v1.3.0 release |
Use the different norms for termination
Since yesterday:
The text was updated successfully, but these errors were encountered: