Could some allocations happen while an exception is being thrown and this buffer is holding the exception backtrace? 🤔🤔

yeah, that's a fantastic question @vilterp... I think @vtjnash is saying no that can't happen, because we basically immediately copy it off the buffer onto a properly sized object, once we know the size (same as we were doing), such as here:

But I frankly can't tell. The comments indicating that we're supposedly using this buffer for rooting implies to me that YES this can ABSOLUTELY happen, in which case 🙅 🙅 no good.

But i would like to get some confirmation from others on this. Just in case, i've started a second PR with the other, simpler approach, of just creating a separate buffer for this, here: #44116

Yes, we use ptls->bt_data so that it is safe across the jl_gc_alloc_buf in that jl_push_excstack. Is that okay?

To perhaps clear up some confusion here... the preallocated bt_data exists fundamentally to avoid allocation in signal handlers — see for example jl_throw_in_ctx in src/signals-unix.c. The point is that inside a signal handler (for things like stack overflow) we must record the backtrace based on the program stack context we have available only within that signal handler. But we're not allowed to call most libc functions in a signal handler and certainly not malloc! The chosen solution is to have a preallocated buffer bt_data available in some thread local storage.

But we can't store backtraces permanently in bt_data because that's thread-local and we want backtraces to survive task switching. Thus when catching an exception we copy it out of bt_data as soon as possible and into the tasks local exception stack storage. However, this task local storage may need to grow (the jl_gc_alloc_buf inside jl_push_excstack, as pointed out by Jameson). So unless that jl_gc_alloc_buf bypasses the memory allocation profiler, the allocation profiler will overwrite the exception backtrace in bt_data.

Fixed by #44116