www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1513] New: try/catch/finally misbehavior on windows

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

           Summary: try/catch/finally misbehavior on windows
           Product: D
           Version: 1.021
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: braddr puremagic.com


bug.d
--------
import std.stdio;

void main()
{
    try
    {
        try
        {
            try
            {
            }
            finally
            {
                writefln("throw ex1");
                throw new Exception("ex 1");
            }

        }
        finally
        {
            writefln("throw ex2");
            throw new Exception("ex 2");
        }
    }
    finally
    {
        writefln("throw ex3");
        throw new Exception("ex 3");
    }
}
-------

dmd 1.021 on windows outputs:
$ ./bug
throw ex1
throw ex2
Error: ex2

dmd 1.021 on linux outputs:
$ ./bug
throw ex1
throw ex2
throw ex3
Error: ex3


--
Sep 17 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513





------- Comment #1 from davidl 126.com  2007-09-18 01:03 -------
err, actually I prefer the windows under hood behavior. Windows prevents you
replace the exception silently. 

For a language to fix such a problem would need to have the stacktrace to
locate where the exception thrown. It's a bit tough to fix the problem.


--
Sep 17 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513





------- Comment #2 from davidl 126.com  2007-09-18 02:39 -------
if i put another try catch block wrap this , everything goes ok

seems it's not SEH related.

I tried some similar code with C __try __except __try __finally blocks. 
It works as expected


--
Sep 18 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513





------- Comment #3 from thomas-dloop kuehne.cn  2007-09-30 05:00 -------
http://www.digitalmars.com/d/statement.html#TryStatement
#
# If an exception is raised in the FinallyStatement and is not caught before
# the FinallyStatement is executed, the new exception replaces any existing 
exception:
#

Added to DStress as
http://dstress.kuehne.cn/run/f/finally_12_A.d


--
Sep 30 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #4 from Brad Roberts <braddr puremagic.com> 2010-05-28 22:51:25 PDT
---
I figured it'd been ages and maybe something had changed to maybe fix this
bug.. nope:

dmd 1.061 on windows:
Error: ex 2
throw ex1
throw ex2

dmd 1.061 on linux:
throw ex1
throw ex2
throw ex3
Error: ex 3

dmd 2.046 on windows:
throw ex1
throw ex2
object.Exception: ex 2

dmd 2.047 (close to svn tip) on linux:
throw ex1
throw ex2
throw ex3
object.Exception: ex 3
--- <cut the stack trace> ---

So.. still different.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513


Don <clugdbug yahoo.com.au> changed:

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


--- Comment #5 from Don <clugdbug yahoo.com.au> 2010-12-10 00:40:35 PST ---
The behaviour of this bug changed in DMD2.048, (possibly as a result of the fix
for bug 4339?)
Now, on Windows DMD2.050 produces:

throw ex1
throw ex2
object.Exception: ex 2
object.Exception: ex 1

Which I don't understand at all.

On D1.065, it is still:
throw ex1
throw ex2
Error: ex 2

Does it still work on D2 Linux?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #6 from Brad Roberts <braddr puremagic.com> 2010-12-10 00:46:09 PST
---
building against tip of trunk for dmd/druntime/phobos, the output:

throw ex1
throw ex2
throw ex3
object.Exception: ex 3
----------------
<snip stack trace>
object.Exception: ex 2
----------------
<snip stack trace>
object.Exception: ex 1
----------------
<snip stack trace>

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #7 from Don <clugdbug yahoo.com.au> 2010-12-10 01:48:42 PST ---
I think the D2 change was actually caused by druntime svn 358. Sean's comment:

Changed how exception chaining works.  Now, the original exception will be
retained and continue propagating even if other exceptions are thrown during
stack unwinding.  These exceptions will be chained via the 'next' pointer and
regarded as collateral damage, as per TDPL.

Is that supposed to apply in this case? Either druntime is wrong, or (more
likely) the spec needs to be updated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #8 from Sobirari Muhomori <dfj1esp02 sneakemail.com> 2010-12-12
09:39:15 PST ---
I'd prefer Sean's description, though the real issue is the 3rd finally block
is not executed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


--- Comment #9 from Don <clugdbug yahoo.com.au> 2010-12-12 23:50:25 PST ---
Reduced test case. Only two finally clauses are required, provided that each
try{} block contains a throw statement. This shows that nesting of finally
statements doesn't work at all on Windows. Raising priority to critical.
----
import std.stdio;

void main()
{
    try
    {
        try
        {
            writefln("throw ex1");
            throw new Exception("ex 1");

        }
        finally
        {
            writefln("throw ex2");
            throw new Exception("ex 2");
        }
    }
    finally 
    {
        writefln("finally");  // never reached
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #10 from Don <clugdbug yahoo.com.au> 2010-12-13 13:20:36 PST ---
I'm not sure that this is a compiler bug. It may be druntime.

With this change:

----
deh.c, _d_framehandler(), line 210

+            else if (prev_ndx == -1)
+            {   // Exception didn't get caught.
+                // Call all the finally blocks skipped in this frame
+                _d_local_unwind(handler_table, frame, ndx);
+            }
        }
    }
    return ExceptionContinueSearch;
----

the finally clauses are called correctly. This isn't a correct patch, 
but I think it demonstrates that the exception tables are set up reasonably
correctly. I couldn't find anything wrong with them.
My limited understanding of exception handling is based on this article:
http://www.microsoft.com/msj/0197/exception/exception.aspx

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 13 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|DMD                         |druntime
         AssignedTo|nobody puremagic.com        |sean invisibleduck.org


--- Comment #11 from Don <clugdbug yahoo.com.au> 2010-12-15 17:22:58 PST ---
This is definitely a druntime issue (though it could be an issue with the C
stdlib). The bug must lie in the druntime/src/rt/deh.c

In the test case, here's my understanding of what happens: 

The first exception is thrown. 
Every try block is queried (in _d_framehandler() )to see if it's handled.
Nothing in main() handles it, but something else does. (I think in this case,
it's a catch-all block around main).
Then, the unwinding starts. _d_framehandler() runs this:
    // Have system call all finally blocks in intervening frames
    int retval = _global_unwind((ESTABLISHER_FRAME *)frame, exception_record);

_global_unwind is a wrapper around the Windows system function RtlUnwind.
That calls _dframehandler() again, with EXCEPTION_UNWIND this time.
This calls _d_local_unwind(), to run all of the finally blocks

_d_local_unwind() is also in druntime/deh.c. 

In the test case, the finally block contains a throw, so the procedure is
repeated. Again it doesn't get caught until the catch-all.
As before, global_unwind and then local_unwind get called.

The first thing _d_local_unwind() does is set up a double-fault exception
handler.

When it begins the unwind, the double-fault handler gets triggered.
The double-fault handler basically just does this:

     if (!(ExceptionRecord->ExceptionFlags & EXCEPTION_UNWIND)) 
        return ExceptionContinueSearch;
     *((ESTABLISHER_FRAME **)DispatcherContext) = EstablisherFrame;
     return ExceptionCollidedUnwind;

Because it returns ExceptionCollidedUnwind, Windows is supposed to abandon the
original unwinding, and the new unwinding
should take over. But that's doesn't seem to be what happens.
No further unwinding occurs. To my suprise, it returns from _global_unwind
into _d_framehandler, back in the original catch handler, and all the variables
seem to be unchanged (so you have no way of detecting what happened).

Dunno where the problem is. Maybe it could be in _global_unwind in the C
runtime?
This stuff is amazingly undocumented by Microsoft.

This is the most detailed info that I've found:
http://www.nynaeve.net/?p=106
See point 7.
And here is more detail about collided unwinds.
http://www.nynaeve.net/?p=107

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 15 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #12 from Don <clugdbug yahoo.com.au> 2010-12-29 00:25:26 PST ---
On D2, the behaviour is wrong on all platforms, not just Windows. Roughly
speaking, Linux does exception chaining incorrectly, and Windows doesn't do it
at all.

These two commits are a first step towards fixing the bug: the problematic code
in the C runtime is replaced with a D implementation (the buggy behaviour isn't
yet changed though).

http://www.dsource.org/projects/druntime/changeset/458
http://www.dsource.org/projects/druntime/changeset/459

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513



--- Comment #13 from Don <clugdbug yahoo.com.au> 2011-01-07 14:20:12 PST ---
Fixed for D2:
http://www.dsource.org/projects/druntime/changeset/482

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 07 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1513


Don <clugdbug yahoo.com.au> changed:

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


--- Comment #14 from Don <clugdbug yahoo.com.au> 2011-01-08 13:36:42 PST ---
And it's now fixed for D1.

http://www.dsource.org/projects/phobos/changeset/2282

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2011