I need some more context here. In what circumstances can we have bt_size == 0? I assume this is valid (or at least unavoidable) in come cases?

Fair enough the context I have encountered this in is #33255. Looking at it again it originates from:

#0  jl_throw_in_ctx (ptls=0x7f8d01b124a0, e=0x7f8cfd246690 <jl_system_image_data+45685008>, sig=11, sigctx=0x7f8d00b649c0) at /home/vchuravy/src/julia/src/signals-unix.c:176
#1  0x00007f8d08f8c424 in segv_handler (sig=11, info=0x7f8d00b64af0, context=0x7f8d00b649c0) at /home/vchuravy/src/julia/src/signals-unix.c:254
#2  <signal handler called>
#3  0x00007f8d08f8266f in gc_scrub_range (low=0x7f8cee09b000 "", high=0x7f8cee49b000 "") at /home/vchuravy/src/julia/src/gc-debug.c:553
#4  0x00007f8d08f8294c in gc_scrub_task (ta=0x7f8cf608a710) at /home/vchuravy/src/julia/src/gc-debug.c:602
#5  0x00007f8d08f829a3 in gc_scrub () at /home/vchuravy/src/julia/src/gc-debug.c:608
#6  0x00007f8d08f7efd2 in _jl_gc_collect (ptls=0x7f8d01b124a0, full=0) at /home/vchuravy/src/julia/src/gc.c:2812

$1 = (jl_value_t *) 0x7f8cfd246690 <jl_system_image_data+45685008>
(rr) p jl_(e)
StackOverflowError()

Which is a safe_restore.

Codecov Report

Merging #33259 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #33259   +/-   ##
=======================================
  Coverage   75.78%   75.78%           
=======================================
  Files         380      380           
  Lines       66452    66452           
=======================================
  Hits        50359    50359           
  Misses      16093    16093

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3f5d56a...50e8da9. Read the comment docs.

So this is the safe_restore codepath... yes, the assert is invalid in that case. I'm fine with just removing it, though it would probably make a tad more sense to change it to

I was thinking about that, but it would make more sense to me to add this invariant close to where it is needed.

Good point. The tricky thing is that this was trying to check an invariant on data coming out of the signal handlers. Hence having it in sig throw is the first place it could intercept that program state. But I messed it up for the exact reason you describe!