Don't segfault when running atexit before jl_threads_init

[vchuravy]

Co-debugged with @staticfloat on ci-dev call

[vtjnash]

CI apparently does not like this. It also might be good to stop running unsupported configurations on buildkite. Though we should start to see threads being supported in releases soon.

cmdlineargs                               (8) |         failed at 2022-06-20T19:59:01.658
Test Failed at /cache/build/default-amdci4-0/julialang/julia-master/julia-72ed6e5bcd/share/julia/test/cmdlineargs.jl:680
  Expression: errors_not_signals(p)
Test Failed at /cache/build/default-amdci4-0/julialang/julia-master/julia-72ed6e5bcd/share/julia/test/cmdlineargs.jl:682
  Expression: p.exitcode == 1
   Evaluated: -9223372036854775808 == 1
Test Failed at /cache/build/default-amdci4-0/julialang/julia-master/julia-72ed6e5bcd/share/julia/test/cmdlineargs.jl:680
  Expression: errors_not_signals(p)
Test Failed at /cache/build/default-amdci4-0/julialang/julia-master/julia-72ed6e5bcd/share/julia/test/cmdlineargs.jl:682
  Expression: p.exitcode == 1
   Evaluated: -9223372036854775808 == 1
Test Failed at /cache/build/default-amdci4-0/julialang/julia-master/julia-72ed6e5bcd/share/julia/test/cmdlineargs.jl:691
  Expression: errors_not_signals(p)
Test Failed at /cache/build/default-amdci4-0/julialang/julia-master/julia-72ed6e5bcd/share/julia/test/cmdlineargs.jl:693
  Expression: p.exitcode == 1
   Evaluated: -9223372036854775808 == 1

      From worker 37:	ERROR: option `-e/--eval` is missing an argument
      From worker 37:	ERROR: option `-e/--eval` is missing an argument
      From worker 37:	ERROR: option `-E/--print` is missing an argument
      From worker 37:	ERROR: option `-E/--print` is missing an argument
      From worker 37:	ERROR: option `-L/--load` is missing an argument
      From worker 37:	ERROR: option `-L/--load` is missing an argument
      From worker 37:	fatal: error thrown and no exception handler available.
      From worker 37:	ErrorException("Invalid CPU name "invalidtarget".")
      From worker 37:
      From worker 37:	signal (11): Segmentation fault
      From worker 37:	in expression starting at none:0
      From worker 37:
      From worker 37:	signal (6): Aborted
      From worker 37:	in expression starting at none:0
      From worker 37:	fatal: error thrown and no exception handler available.
      From worker 37:	ErrorException("Invalid CPU name "invalidtarget".")
      From worker 37:
      From worker 37:	signal (11): Segmentation fault
      From worker 37:	in expression starting at none:0
      From worker 37:
      From worker 37:	signal (6): Aborted
      From worker 37:	in expression starting at none:0

[vchuravy]

How is setting JULIA_NUM_THREADS an unsupported configuration?

CI apparently does not like this.

So yeah this isn't complete :)

[vtjnash]

How is setting JULIA_NUM_THREADS an unsupported configuration?

CI apparently does not like this.

Because CI apparently does not like this

[staticfloat]

Alright, that latest fix has solved the majority of problems, but i686-linux-gnu still segfaults on julia -C invalid.

Digging in with a debugger, we fail at a different point on i686-linux-gnu, because we don't hit the CX16 failure branch, but instead hit the "Invalid CPU Name" error. This is much later in the bringup process, but still not early enough that we can do things like call jl_DI_for_fptr, which is what we try to do when we print backtraces due to calling jl_errorf().

I've now pushed a commit that avoids printing backtraces when jl_errorf() is called, in a similar manner to how jl_error() avoids backtraces, but I had to extend the guard condition to use other data structures, as it turns out that the existing guard condition was insufficient. I don't know if this is the proper guard condition (maybe we should create a jl_can_collect_backtraces sentinel global value?) but CI will tell us if this works or not.

[staticfloat]

Alright, this is now fixing the identified problems with running atexit hooks, however I'm quite unsatisfied with my solution of using jl_error_sym as a sentinel for the fact that LLVM has been initialized or not. Is there a more direct method I can use, or should I add a jl_llvm_initialized sentinel value or something?

[JeffBezanson]

Maybe we should have jl_init_llvm handle filling in the libjulia-codegen function pointers, so the system just behaves as if codegen is not available before it's initialized?

[staticfloat]

Following Jeff's advice on Slack, I have removed the potentially more controversial parts of this PR, manually inlining the "print and exit" logic from jl_error* in the cases where we know it is too early to backtrace. Looking on CI, I got a natural green flush, and have verified that there are no mysterious core files uploaded, so I'm calling this a victory.

[staticfloat]

Further discussion about making jl_error* safe can be found in this issue: #45847

[vchuravy]

Thanks Elliot for getting this over the line!