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

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?

On Apr 18, 2012, at 11:48 AM, Andrew Lauritzen wrote: > 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: This is a regression from 2.058, correct? Please file a bug report either way. Nothing relevant should have changed in core.thread though.

> This is a regression from 2.058, correct? Please file a bug report either way. Nothing relevant should have changed in core.thread though. Nope it happened in 2.058 as well (which is the first one I tested... I'm new to D :). Where's the best place to file a bug? In the bugs section of the forum or is there a formal tracker?

On Apr 18, 2012, at 3:47 PM, Andrew Lauritzen wrote: >> This is a regression from 2.058, correct? Please file a bug report either way. Nothing relevant should have changed in core.thread though. > > Nope it happened in 2.058 as well (which is the first one I tested... I'm new to D :). Where's the best place to file a bug? In the bugs section of the forum or is there a formal tracker? http://d.puremagic.com/issues/

On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote: > I'm still interested in if anyone has any suggested workarounds or experience using Win32 fibers in D2 as well. The x32 Windows code should be pretty well tested. If this is using the x64 code though, that's all quite new. I'll give this a try when I find some time, but can't suggest a workaround offhand. It almost sounds alignment-related, which could be tricky.

> The x32 Windows code should be pretty well tested. If this is using the x64 code though, that's all quite new. I'll give this a try when I find some time, but can't suggest a workaround offhand. It almost sounds alignment-related, which could be tricky. This is using the x86 (32-bit) code, so I'm not sure what could be going wrong. Is it well-tested on Windows too? Seems like something about the interaction between the fiber context/stack and SEH is not happy.

On Thursday, 19 April 2012 at 01:32:34 UTC, Andrew Lauritzen wrote: >> The x32 Windows code should be pretty well tested. If this is using the x64 code though, that's all quite new. I'll give this a try when I find some time, but can't suggest a workaround offhand. It almost sounds alignment-related, which could be tricky. > > This is using the x86 (32-bit) code, so I'm not sure what could be going wrong. Is it well-tested on Windows too? Seems like something about the interaction between the fiber context/stack and SEH is not happy. Gah, not this again. *sigh* It is semi-well tested as in that I'm relying on it for async I/O in Thrift, and its test suite now passes on every Windows box I tested. If you can spare the time, it would be great if you cloud download DMD 2.057 and try if the test case also fails with it on your setup. The reason is that I changed the way the top of the SEH chain is set up for fibers in 2.058 to make it work on Windows Server 2008/2008 R2, and maybe I inadvertently screwed up the stack alignment/… (you have to reverse-engineer the gritty details of SEH as you are going, and you never know whether you really »got it right« in terms of Microsoft's internal specs). David

> Gah, not this again. *sigh* > > It is semi-well tested as in that I'm relying on it for async I/O in Thrift, and its test suite now passes on every Windows box I tested. > > If you can spare the time, it would be great if you cloud download DMD 2.057 and try if the test case also fails with it on your setup. The reason is that I changed the way the top of the SEH chain is set up for fibers in 2.058 to make it work on Windows Server 2008/2008 R2, and maybe I inadvertently screwed up the stack alignment/… (you have to reverse-engineer the gritty details of SEH as you are going, and you never know whether you really »got it right« in terms of Microsoft's internal specs). Yeah I feel your pain on Windows SEH stuff and lack of docs. I actually work with someone who used to work on Visual C++ so I'll see if I can get any info/links out of him on the subject that may be helpful :) In the mean time, as per the issue in the discussion, the plot has thickened to include there being apparently side-effects to putting break-points/debugging the code itself, which throws a big wrench into my analysis of what is going wrong. Suffice it say, I'm not sure it's actually D's problem, although I'm still worried by the "Stack Overflow" message. I'll grab 2.057 and give it a test though to see if the behavior is any different. Thanks!

Forums