digitalmars.D.bugs - [Issue 8293] New: Small amount of static analysis to avoid certain destructor bugs
- d-bugmail puremagic.com (42/44) Jun 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8293
- d-bugmail puremagic.com (14/14) Jan 16 2013 http://d.puremagic.com/issues/show_bug.cgi?id=8293
- d-bugmail puremagic.com (14/15) Jun 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=8293
http://d.puremagic.com/issues/show_bug.cgi?id=8293 Summary: Small amount of static analysis to avoid certain destructor bugs Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc A short thread in D.learn about a core.exception.InvalidMemoryOperationError: http://forum.dlang.org/thread/js649p$1707$1 digitalmars.com Caused by this code: class X { string[string] s; this() { s["s"] = "S"; } ~this() { s.remove("s"); } } void main() { X x = new X(); } Jonathan M Davis:you should never do anything in a class' destructor/finalizer which could ever trigger the GC in any way.In past I have seen other similar bugs discussed in D.learn. I think a small amount of static analysis code added to the D front-end can statically avoid every bug of this kind. This code has to look inside ~this(){} and work recursively (like purity and nothrow enforcement do), searching for functions that perform GC activity. (This is a bit different from the enforcement of the noheap annotation I have suggested in Issue 5219 because it's OK to manage C-heap memory inside the destructor, while noheap looks for C-heap activity too (malloc/realloc/calloc)). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8293 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.com The problem is that using the gc in a destructor is perfectly valid for two reasons: - InvalidMemoryOperationError is just an implementation deficiency - You can manually call the destructor The first reason will go away eventually. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 16 2013
http://d.puremagic.com/issues/show_bug.cgi?id=8293 Marco Leise <Marco.Leise gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Marco.Leise gmx.de- You can manually call the destructorWhich more or less means that if such an object is allocated with new, there must always be a pointer to it to prevent automatic collection. Because it has to be manually destroyed to be safe. Or can the GC be improved in this regard? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 18 2013