Hello.

Thanks for the fix in #6870.

I ran into another crash after applying that fix.
Same as before, I'm not sure it is my code or not.

Crash

This happened in an mruby app using mruby-task.

This happened after this fix was applied:

8d8a01ecc vm.c: defer task switch across C call boundary

The crash was a SIGBUS inside mrb_gc_mark:

frame #0  mrb_gc_mark(obj=0x5a5a5a5a5a5a5a5a) at gc.c:863
frame #1  gc_mark_children(obj=0x6be72f2600) at gc.c:712
frame #5  mrb_incremental_gc at gc.c:1373
frame #6  mrb_obj_alloc_core(MRB_TT_HASH) at gc.c:579
frame #9  mrb_hash_new_capa at hash.c:1246
frame #10 mrb_vm_exec at vm.c:3524
frame #11 execute_task at task.c:354
frame #14 mrb_task_run at task.c:499

Details

The object being marked from the gray stack looked corrupted:

obj=0x6be72f2600
obj->c=0x5a5a5a5a5a5a5a5a
obj->tt=MRB_TT_RATIONAL | 0x40
obj->flags=0x5a5a5

That same object pointer was still present on the VM stack:

stbase=0x6be69bce00
pointer found at 0x6be69bd2c0
slot=152

That slot was inside the current call frame:

file=mruby-tui/mrblib/tui/widgets/markdown/inline.rb
mid=segment_for
nregs=18
ci->stack - c->stbase=135
slot_in_frame=17

So the core appears to show GC processing register R17 in the active
segment_for frame, and that register contains a corrupted object pointer.

Notes

The crash happened during hash allocation:

mrb_obj_alloc_core(MRB_TT_HASH)
  -> mrb_incremental_gc
  -> gc_mark_children
  -> mrb_gc_mark

The bad slot does not appear to be a named local. The irep for segment_for
had nregs=18, while the bad slot was R17.

I tried reducing this without libcurl, but have not reproduced it yet.

Does this help?
Can I provide more information?
Thanks.