Try to fix deadlock in code loading #28416
Conversation
If a precompiled package's init function tries to itself require that package (e.g. by importing a symbol from a submodule of that package), we would run into a deadlock. Fix that by delaying the running of initializers until after we've had a chance to register any root module. Fixes #26028
|
FreeBSD CI workers got randomly frozen builds after this PR merged. All the following builds are on 0e32871
|
|
I'm hesitant to backport this if it causes FreeBSD issues. |
|
@iblis17 I'm not sure this is related. Those builds ran at about the same time and both hung at a place where they would be trying to do network I/O. The builds afterwards failed with a network error and the ones after that succeeded. Could there have been intermittent network problems? |
|
Seems no hanging now. It may be network issue. (But there aren't any exceptions raised. What's the timeout config of our libgit2. |
If a precompiled package's init function tries to itself require that package (e.g. by importing a symbol from a submodule of that package), we would run into a deadlock. Fix that by delaying the running of initializers until after we've had a chance to register any root module. Fixes #26028 (cherry picked from commit 0e32871)
| @@ -611,7 +611,8 @@ end | |||
| # or an Exception that describes why it couldn't be loaded | |||
| # and it reconnects the Base.Docs.META | |||
| function _include_from_serialized(path::String, depmods::Vector{Any}) | |||
| restored = ccall(:jl_restore_incremental, Any, (Cstring, Any), path, depmods) | |||
| sv = ccall(:jl_restore_incremental, Any, (Cstring, Any), path, depmods) | |||
| restored = sv[1] | |||
There was a problem hiding this comment.
@Keno, this looks incorrect. The return value from jl_restore_incremental is not indexable in case the return value is an exception?
There was a problem hiding this comment.
This same commit changed the regular return value to be a tuple, but you are correct that something got messed up with the other return path in this function. Wanna fix it and ideally at a test case ;)?
If a precompiled package's init function tries to itself require that package (e.g. by importing a symbol from a submodule of that package), we would run into a deadlock. Fix that by delaying the running of initializers until after we've had a chance to register any root module. Fixes #26028
If a precompiled package's init function tries to itself require that
package (e.g. by importing a symbol from a submodule of that package),
we would run into a deadlock. Fix that by delaying the running of
initializers until after we've had a chance to register any root module.
Fixes #26028