www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7938] New: Stack overflow/access violation when throwing exceptions from fibers

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938

           Summary: Stack overflow/access violation when throwing
                    exceptions from fibers
           Product: D
           Version: D2
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: andrew.lauritzen gmail.com


--- Comment #0 from Andrew Lauritzen <andrew.lauritzen gmail.com> 2012-04-18
16:04:59 PDT ---
Throwing exceptions from fibers seems buggy on Windows in both 2.058 and 2.059
(and perhaps earlier). The following modification to the example given in the
unit test (adding unrelated exception handling to the same scope) fails with a
"Stack Overflow" exception, followed by 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.

Tested on several machines in Windows 7 x64 (but with a 32-bit D2 application
of course).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #1 from Don <clugdbug yahoo.com.au> 2012-04-18 21:11:50 PDT ---
I wonder if this is related to bug 6329.

I can't reproduce this. If

import core.thread;
void main() 
{

}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938



--- Comment #2 from Don <clugdbug yahoo.com.au> 2012-04-18 21:13:59 PDT ---
I can't reproduce this. If I wrap the example in this 
import core.thread;
void main() 
{
 ...code from comment 0...
}

it works fine. But maybe that's different to what you've done. Please provide a
complete example.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938



--- Comment #3 from Andrew Lauritzen <andrew.lauritzen gmail.com> 2012-04-18
21:28:03 PDT ---
Hmm yeah that was a portion pasted into a large file - should have been
independent, but here we go with a separately tested case:

import core.thread;
import std.stdio;

class A : core.thread.Fiber
{
    public this()
    {
        super(&run);
    }

    public void run()
    {
        throw new Exception("msg");
    }
}

void main() 
{
    auto a = new A();
    try
    {
        a.call();
    }
    catch (Exception e)
    {
        writeln(e.msg);
    }
}

This is about the simplest you can get I think, but running it in Debug with
MSVC and Visual D 0.3.31 with a breakpoint on the writeln you'll see the
following in the debugger:

First-chance exception at 0x5d66bc13 in TestFiberExceptions.exe: 0xC00000FD:
Stack overflow.
First-chance exception at 0x769ab9bc in TestFiberExceptions.exe: 0xE0440001:
0xe0440001.
First-chance exception at 0x769ab9bc in TestFiberExceptions.exe: 0xE0440001:
0xe0440001.

In this example it doesn't seem to actually crash the program, but in more
complex examples you'll get a stream of access violations and nonsense after
the initial stack overflow. I can try to make it more complex to demonstrate
this behavior as well, but presumably the above output is indicative of a
problem in and of itself?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938



--- Comment #4 from Andrew Lauritzen <andrew.lauritzen gmail.com> 2012-04-18
21:46:38 PDT ---
Upon some further messing around, I'm starting to wonder whether this has
something to do with placing breakpoints as well. I've definitely seen issues
without that, but in the simple example, if you place a breakpoint on the throw
and then place one on the writeln and also add another writeln("hello"); to the
end of main and place a breakpoint on it you can get some weird behavior.

1) If upon breaking on the throw line, you "continue" (F5), you'll end up in
the exception handler as expected.

2) If instead you "step over" or "step into" (F10), it'll appear to just
continue on as if the exception didn't happen and want to step into
disassembly. Then if you continue (F5) you'll skip the exception handler
all-together and end up on the writeln("hello") line...

Now I realize some/all of this oddity may be VisualD and related tool's issue,
but I figured it might be related or shed some light on this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938



--- Comment #5 from Andrew Lauritzen <andrew.lauritzen gmail.com> 2012-04-18
22:07:53 PDT ---
Hmm so interestingly I can only seem to repro the access violation portion of
this when breaking in the debugger, and since I'm using VisualD, etc. for that
this may not actually be an issue with D2 itself.

I'm still curious (and nervous) about the Stack Overflow message, but I'm
willing to close this one and throw it over to the VisualD people instead given
that it seems like that may be where the issue lies; certainly if no one else
has seen a similar issue. If I bump into a test case that I can repro without a
debugger, I'll definitely open a new issue.

Sorry for the confusion - I'm not used to assuming that breaking in a debugger
could cause side-effects :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938


SomeDude <lovelydear mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear mailmetrash.com


--- Comment #6 from SomeDude <lovelydear mailmetrash.com> 2012-04-21 12:46:26
PDT ---
(In reply to comment #5)

 Sorry for the confusion - I'm not used to assuming that breaking in a debugger
 could cause side-effects :)


Actually, on concurrent programming, it does, and the debugger is practically
useless, because you won't be able to see concurrent accesses. You should
really use traces.

Anyway, both test codes compile and run fine on my machine (2.059 Win32).
Should we close ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 21 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7938


Andrew Lauritzen <andrew.lauritzen gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #7 from Andrew Lauritzen <andrew.lauritzen gmail.com> 2012-04-21
23:13:35 PDT ---
I'm not using fibers for concurrency (there is none in this program), and I'm
well-aware of how debugging parallel programs works :) See the accompanying
thread on the D forums for a description and discussion of what I and others
are using the fibers for.

Fine with closing this for now. As discussed there are still some loose ends
(stack overflow messages, bizarre debugger behavior on exception throwing) but
I'll file more specific bugs and test cases if I run into issues that can be
triggered without the debugger.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 21 2012