www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6821] New: core.exception.OutOfMemoryError on dtor field test of class-embedded struct

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

           Summary: core.exception.OutOfMemoryError on dtor field test of
                    class-embedded struct
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2011-10-16
20:37:24 PDT ---
struct Bar
{
    this(int x) {}

    uint _count;

    ~this()
    {
        assert(this._count > 0);
    }        
}

class Foo
{
    this()
    {
        bar = Bar(1);
    }

    Bar bar;
}

void main()
{
    auto foo = new Foo();
}

$ dmd test.d && test.exe
$ core.exception.OutOfMemoryError

The "assert(this._count > 0);" triggers this exception. I can only recreate
this if "bar" is a field of class Foo, and not just a temporary inside Foo's
constructor or anywhere else.

I'm labeling this as critical since these checks are prevalent throughout the
CairoD library and this seems like some kind of memory corruption issue.

I've also had this bug appear and disappear based on the current path of
invocation of an executable, IOW sometimes an app would throw this exception on
exit if it was invoked on a directory UP from the current application
directory, while in all other cases the exception would not be thrown.

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



--- Comment #1 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2011-10-16
20:39:37 PDT ---

 I've also had this bug appear and disappear based on the current path of
 invocation of an executable, IOW sometimes an app would throw this exception on
 exit if it was invoked on a directory UP from the current application
 directory, while in all other cases the exception would not be thrown.


When I say "an" executable I mean a much more complicated app than this small
test case.

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


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com
           Platform|Other                       |All
         OS/Version|Windows                     |All


--- Comment #2 from yebblies <yebblies gmail.com> 2011-10-17 21:10:30 EST ---
I'm guessing the issue here is:

Currently attempting to allocate during a garbage collection throws an oom
error.  This is due to limitations in the current gc implementation, previously
it just corrupted memory.  As the Foo object is only destroyed when the final
collection occurs, the assert failing in the destructor tries to allocate an
AssertError and fails.

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


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

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


--- Comment #3 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2011-10-17
09:03:17 PDT ---
Because AssertError is an object, I understand. I think it was Vladimir who
changed it to throw an exception, which is a good thing rather than have it
corrupt memory. I guess this isn't so critical then, although a note of what
you shouldn't be doing in a dtor should be added to the docs.

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


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

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


--- Comment #4 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2012-01-04
06:44:01 PST ---
I think it's ok to close this, this is a GC implementation issue and is not
necessarily a bug.

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


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow gmail.com


--- Comment #5 from Vladimir Panteleev <thecybershadow gmail.com> 2012-01-04
06:56:21 PST ---
(In reply to comment #3)

 Because AssertError is an object, I understand. I think it was Vladimir who
 changed it to throw an exception, which is a good thing rather than have it
 corrupt memory.


Yup. The newer Druntime versions have a dedicated exception class for this
error (InvalidMemoryOperationError), which should be Google-able enough to
clear confusion regarding it.

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