Bug 6821 – core.exception.OutOfMemoryError on dtor field test of class-embedded struct

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.

> 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.

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.

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.

I think it's ok to close this, this is a GC implementation issue and is not necessarily a bug.

(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.