www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8293] New: Small amount of static analysis to avoid certain destructor bugs

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from bearophile_hugs 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: -------
Jun 25 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8293


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com


--- Comment #1 from yebblies <yebblies gmail.com> 2013-01-17 13:59:22 EST ---
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
prev sibling parent d-bugmail puremagic.com writes:
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


--- Comment #2 from Marco Leise <Marco.Leise gmx.de> 2013-06-18 15:27:46 PDT ---
(In reply to comment #1)
 - You can manually call the destructor

Which 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