FreeBSD segfaults with std.parallelism

I've spent some serious time looking into the FreeBSD std.parallelism segfaults.  I'm at a complete loss as to what could be causing them or how to fix them.  Here are some observations.  Someone please offer any suggestions you have.

1.  I'm able to reproduce these, though much more sporadically, on Windows and Linux, by executing the unit test in a loop.

2.  On FreeBSD running GDB on the core dump shows stack traces that should be impossible.  Every time the program crashes, the function at the top of the stack should be unreachable from the second function from the top.  (It shouldn't even be indirectly reachable, i.e. inlining couldn't explain it.)  On both Linux and FreeBSD, the program counter ends up at illegal places in between instructions.  Even more weirdly, the address that the program counter ends up at when the segfault happens seems deterministic for any given platform and compiler settings.  Is there a good debugger for Windows that will give me stack traces and stuff like GDB?

3.  The triggering test is:

     auto lmchain = poolInstance.map!"a * a"(
         poolInstance.map!sqrt(
             poolInstance.asyncBuf(
                 iota(3_000_000)
             )
         )
     );
     foreach(i, elem; parallel(lmchain)) {
         assert(approxEqual(elem, i));
     }

In other words, it's the test that uses everything together (including Task and amap() under the hood), the hardest one to debug.

IIUC, the instruction stream can't be overwritten by a buggy program because the code pages are marked read-only.  The only other explanation I can think of for how the program counter could be corrupted is if some race condition corrupts either a function pointer or a return address on the stack.  However, in this case the address that the program counter ends up at when the segfault happens should be less deterministic.

Forums