Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
October 17, 2011 [Issue 6821] New: core.exception.OutOfMemoryError on dtor field test of class-embedded struct | ||||
---|---|---|---|---|
| ||||
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 [Issue 6821] core.exception.OutOfMemoryError on dtor field test of class-embedded struct | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 [Issue 6821] core.exception.OutOfMemoryError on dtor field test of class-embedded struct | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 [Issue 6821] core.exception.OutOfMemoryError on dtor field test of class-embedded struct | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 [Issue 6821] core.exception.OutOfMemoryError on dtor field test of class-embedded struct | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 [Issue 6821] core.exception.OutOfMemoryError on dtor field test of class-embedded struct | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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: ------- |
Copyright © 1999-2021 by the D Language Foundation