Windows: Throwing Exceptions from Fibers in D2.059: Access Violation

[Andrew Lauritzen]

I sent this to the mailing list but as it appears to be awaiting 
moderation, here might be a more appropriate place for discussion.

Throwing exceptions from fibers seems buggy on Windows in the 
latest D2 runtime. Even a small modification to the example given 
in the unit test (adding unrelated exception handling to the same 
scope) fails with a "Stack Overflow" exception then tons of 
access violations:

    enum MSG = "Test message.";
    string caughtMsg;
    (new Fiber({
        try
        {
            throw new Exception(MSG);
        }
        catch (Exception e)
        {
            caughtMsg = e.msg;
        }
    })).call();
    assert(caughtMsg == MSG);
    // Add these two lines
    try { caughtMsg = "Hello"; }
    catch (Exception e) { caughtMsg = "World"; }

It seems brittle as well. Adding a "assert(caughtMsg == 
"Hello");" to the end of the above program for instance avoids 
the access violations (but still shows the stack overflow in the 
debugger). Similarly playing with the caughtMsg assignments 
(omitting one) or adding another assert at the end of the program 
will sometimes cause the program to run without error. This is in 
debug mode with optimizations off to theoretically avoid dead 
code elimination, but clearly something is easily thrown off.

I take it that not too many people are using Fibers on windows, 
but I really need them for a project that I'm working on. 
Alternatively I've considered trying to wrap native Win32 API 
Fibers to accomplish something similar, but I'm not sure of the 
difficulty of that. Anyone done this or have recommendations of a 
similar workaround? I really do need both fibers/coroutines and 
exceptions to express what I'm trying to do in a clean and 
efficient manner. I've considered switching to Go, but I've got 
some really handy mixins in D that would become copy-pasted stuff 
in Go presumably.

I'm running a 32-bit D application on Windows 7 x64. I've tried 
on several machines with the same results, and the same issue was 
present in 2.058 as well.

Any ideas?