Hello.

I'm not sure if this bug is within my own code or not.
I have not been able to create a standalone reproduction.

Crash

I ran into this crash in an mruby app using mruby-task. The crash happened
while a Ruby block was being called from C via mrb_yield_argv.

Assertion failed: ((obj)->tt != MRB_TT_FREE), function mrb_gc_mark,
file .../mruby/src/gc.c
Abort trap (core dumped)

This was on mruby HEAD:

d2a1c43a5

Details

Relevant backtrace:

frame #4  mrb_gc_mark(obj=0x272eb88f678) at gc.c:1008
frame #5  mark_context_stack(c=0x272eb272a50) at gc.c:813
frame #10 mrb_incremental_gc at gc.c:1519
frame #11 mrb_obj_alloc_core(MRB_TT_STRING) at gc.c:685
frame #15 mrb_vm_exec at vm.c:3507
frame #16 mrb_vm_run at vm.c:1693
frame #18 yield_with_attr at vm.c:1270
frame #19 mrb_yield_argv at vm.c:1326
frame #36 execute_task at task.c:354
frame #39 mrb_task_run at task.c:499

I added a temporary check in mark_context_stack before mrb_gc_mark. The value
being marked was already free:

slot=208
obj=0x272eb88f678
obj->tt=MRB_TT_FREE

That slot was inside the current call frame:

ciidx=39
ci->stack - c->stbase = 198
slot_in_frame=10
mid=merge_function!
nregs=12

So the core appears to show GC marking register R10 in the active
merge_function! frame, and that register contains a freed object pointer.

Notes

The assertion happened during string allocation:

mrb_obj_alloc_core(MRB_TT_STRING)
  -> mrb_incremental_gc
  -> mark_context_stack
  -> mrb_gc_mark

The bad slot does not appear to be a named local. The irep for merge_function!
had nlocals=8 and nregs=12, while the bad slot was R10.

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

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