This breaks the interpreter on Windows: https://github.com/crystal-lang/crystal/actions/runs/20170611171/job/57926651383

We probably need to pay special attention to the interpreter, because we spawn fibers from the interpreted program in the interpeter itself. With -Dexecution_context -Dpreview_mt this means all fibers in the interpreter run in a parallel context!
So it's actually surprising that we don't see any problems on other platforms...

Good point. We shouldn't resize the default context and instead create a dedicated parallel context for codegen only.

Or create a concurrent context for running the interpreted code.

Or both.

What's weird is that preview_mt worked (oh, no stealing) 🤨

I finally reproduced locally. I tried a few things (always run interpreter in a specific single-threaded context, disabling the PCRE2 thread local, but to no avail.

Then I looked at the backtrace... and the error is on the following line:

1. PCRE2 calls back into Crystal
2. the interpreter checkouts a fiber stack (to interpret the callback) from a local Fiber::StackPool;
3. the interpreter tries to clear the stack;
4. memset segfaults => I assume the stack has been freed?

This is related to reusing a dead stack fiber set on the current thread:

reusing dead stack Fiber::Stack(@pointer=Pointer(Void)@0x1bbe9550000, @bottom=Pointer(Void)@0x1bbe9d50000, @size=8388608, @reusable=true)
Invalid memory access (C0000005) at address 0x1bbe9550000

Which would point the issue to the following line:

And this is likely related to the interpreter always releasing the fiber stack immediately:

I'll try to add an option to Fiber::StackPool to disable recycling a dead fiber stack, because this is not a fiber stack pool, this is a stack pool for C callbacks!

The bug is fixed in #16518. See this example run.