Thread overview
[Issue 6821] New: core.exception.OutOfMemoryError on dtor field test of class-embedded struct
Oct 17, 2011
Andrej Mitrovic
Oct 17, 2011
Andrej Mitrovic
Oct 17, 2011
yebblies
Oct 17, 2011
Andrej Mitrovic
Jan 04, 2012
Andrej Mitrovic
Jan 04, 2012
Vladimir Panteleev
October 17, 2011
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: -------
October 17, 2011
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: -------
October 17, 2011
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: -------
October 17, 2011
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: -------
January 04, 2012
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: -------
January 04, 2012
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: -------