Still gc crash

[sgaure]

It seems there are still some problems in the gc with the recent master, despite the fix in #53355.

I'm running

Julia Version 1.12.0-DEV.89
Commit 35cb8a556b* (2024-02-27 06:12 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 24 × AMD Ryzen Threadripper PRO 5945WX 12-Cores
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver3)
Threads: 1 default, 0 interactive, 1 GC (on 24 virtual cores)
Environment:
  JULIA_EDITOR = emacs -nw

compiled and installed on this machine.

Here is an MWE which frequently results in a crash. It runs fine in version 1.10.1 installed from snap on Ubuntu 23.10.

using .Threads

function fun(N)
    parts = Iterators.partition(1:N, 1 + N ÷ nthreads())

    tasks = [@spawn begin
                 s = Vector{Float64}(undef, length($part))
                 base = first($part)
                 for i in $part
                     s[i-base+1] = 1/i
                 end
                 return s
             end for part in parts]

    mapreduce(vcat, tasks) do t
        fetch(t)::Vector{Float64}
    end
end

println(sum(fun(42)))

println(sum(fun(10_000_000)))

Without the line with fun(42) it seems to work.

With the above program in the file crash.jl, a typical crash looks like

$ julia -t 12 -e 'include("crash.jl")'
4.326742806648339
GC error (probable corruption)
C error (probable corruption)
Allocations: 618918 (Pool: 618895; Big: 23); GC: 1
Allocations: 618918 (Pool: 618895; Big: 23); GC: 1

!!! ERROR in jl_ -- ABORTING !!!

!!! ERROR in jl_ -- ABORTING !!!
GC error (probable corruption)

[1214416] signal 6 (-6): Aborted

[1214416] si618918 (Pool: 618895; Big: 23); GC: 1
in expression starting at none:0
 Big: 23); in expression starting at none:0
Allocations: 618918 (Pool: 618895; Big: 23); GC: 1
Aborted (core dumped)

[gbaraldi]

This triggers an assert for me. Looking further into it

[vtjnash]

In analysis of this, we found there is a safepoint that was introduced into JL_TRY in 3f23533 (the safepoint could be there before, but only in rare cases where unlocks was true or defer_signal was true, which typically wouldn't be true in these cases). This safepoint had been intentionally hidden from the gc-analyzer in the definition of JL_TRY, so we didn't notice it cause failures in the checker.