[Issue 8293] New: Small amount of static analysis to avoid certain destructor bugs
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Jun 25 04:32:32 PDT 2012
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 at puremagic.com
ReportedBy: bearophile_hugs at eml.cc
--- Comment #0 from bearophile_hugs at eml.cc 2012-06-25 04:34:59 PDT ---
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: -------
More information about the Digitalmars-d-bugs
mailing list