Freeze when switching to pkg mode, when Pkg has not been loaded already.

[sgaure]

This causes a freeze:

$ julia --startup=no -p 1 -t 1
(@v1.11) pkg> status

https://discourse.julialang.org/t/version-1-11-1-argument-issue/121408

Julia Version 1.11.1
Commit 8f5b7ca12ad (2024-10-16 10:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 16 × AMD Ryzen 7 2700X Eight-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver1)
Threads: 1 default, 0 interactive, 1 GC (on 16 virtual cores)
Environment:
  JULIA_NUM_THREADS = 16
  JULIA_EDITOR = emacs -nw

[IanButterworth]

Can you try

$ julia --startup=no -p 1 -t 1 -ie "@time using Pkg"

And then see if pkg mode works

[sgaure]

Yes. It works if Pkg is imported first. Also with julia ... -L file.jl where file.jl contains import Pkg.

[IanButterworth]

Is the freeze indefinite or does it just take a while?

[giordano]

Is this related to #56054 (and #56207), even if condition to trigger the issue is different?

[sgaure]

At least an hour, and can't be interrupted by either ^C or ^Z, and does not use CPU. gdb reveals that thread 1 is in uv__io_poll, whereas the other threads are in pthread_cond_wait (blas threads).

[sgaure]

It could be related to the -O3 stuff. I can replicate the -O3 hang, but it too goes away if I preload Pkg with a suitable -L file.jl.

[IanButterworth]

@vtjnash seems specific to require_stdlib. What can we do to further debug this?

[vtjnash]

According to lldb, it happens because load_pkg wants to take the Base.require_lock, but it is forbidden to call into any of the requires logic while holding that lock (that must lead to deadlocks).

Aside: it looks like that REPLExt.__init__ also does wildly unsafe things, like mutate a lot of global arrays without any locks concurrently with expecting them to be simultaneously be getting modified by the REPL itself.