www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7018] New: finally block not executed for assertions

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

           Summary: finally block not executed for assertions
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: dawg dawgfoto.de


--- Comment #0 from dawg dawgfoto.de 2011-11-26 15:01:32 PST ---
void main(string[] args)
{
    try
    {
        assert(args.length > 1);
    }
    finally
    {
        extern(C) void printf(const char* format, ...);
        printf("finally\n");
    }
}

---

The issue is that AssertExp is marked as nothrow.


This bug is responsible for the deadlocks in druntime unittests.

synchronized(foo)
{
  assert(exp);
}

is rewritten as

_d_monitorenter(__sync);
assert(exp);
_d_monitorexit(__sync);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7018


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |INVALID


--- Comment #1 from Walter Bright <bugzilla digitalmars.com> 2011-11-26
20:45:19 PST ---
The behavior is correct. assert throws a non-recoverable exception, which means
that finally blocks are not executed.

If a test depends on finally being executed after an assert, then the test case
is wrong.

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


Brad Roberts <braddr puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |braddr puremagic.com
         Resolution|INVALID                     |
            Summary|finally block not executed  |synchronized + assert ==
                   |for assertions              |evil results


--- Comment #2 from Brad Roberts <braddr puremagic.com> 2011-11-26 21:40:25 PST
---
I'm going to re-open for a second.  I don't disagree with the part about assert
+ try/catch/finally, I agree that there's, at a minimum, a diagnostic issue
here.

There's no case in which synchronized { assert } is valid.

Additionally, if this is indeed the source of the druntime deadlock, THAT bug
isn't invalid and still needs to be fixed.

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



--- Comment #3 from Walter Bright <bugzilla digitalmars.com> 2011-11-26
22:08:27 PST ---
(In reply to comment #2)

 There's no case in which synchronized { assert } is valid.


There is because assert is for checking for logic errors, and then it is
supposed to abort the program. It is not expected to clean up finally blocks,
release mutexes, etc.

AssertExp *is* nothrow.

If there are bugs in the druntime tests, those need to be identified and
submitted.

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



--- Comment #4 from dawg dawgfoto.de 2011-11-27 04:34:47 PST ---
I agree with nothrow.
Not sure how to handle synchronized { assert }.
Maybe the root cause is that the runtime fails to abort
a program with Errors being thrown in different threads, is it?

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


Sean Kelly <sean invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean invisibleduck.org


--- Comment #5 from Sean Kelly <sean invisibleduck.org> 2011-11-30 16:34:21 PST
---
If no cleanup should be performed, why is an assertion failure represented as
an exception in the first place?  And what about the other Errors that can
legally be generated within a nothrow block (like OutOfMemoryError) but are
technically recoverable?

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


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com


--- Comment #6 from Jonathan M Davis <jmdavisProg gmx.com> 2011-11-30 16:57:07
PST ---
They're Errors, not Exceptions, so they are _not_ expected to be recoverable.
The fact that they are exceptions allows you to get more meaningful data on
failures (e.g. stack traces), and you _can_ technically recover from them in
very controlled circumstances but _only_ in very controlled circumstances where
you really know what you're doing and you're very careful to make sure that
it's actually safe to do the recovery. In the general case, they are _not_
expected to be recoverable and so are not treated that way. Once an Error is
thrown, the program is in an undefined state, so it's questionable that you
even _can_ recover except in very controlled circumstances.

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