http://d.puremagic.com/issues/show_bug.cgi?id=5653

           Summary: Allocating in a destructor called during a GC corrupts
                    memory
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: patch
          Severity: critical
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: thecybershadow@gmail.com


--- Comment #0 from Vladimir <thecybershadow@gmail.com> 2011-02-25 19:02:00 PST ---
Created an attachment (id=922)
Very simple patch against D1's gcx.d which throws OutofMemory when allocating
during a GC run

D's current garbage collector is completely unprepared to handle an allocation which is called by a finalizer. Such an allocation puts D's GC into an inconsistent state, which ultimately leads to memory corruption.

The GC should either forbid allocating in destructors (by throwing an
exception), or properly support it (which may be non-trivial).

If the first solution is chosen, it should be noted that there are instances of allocations in destructors in Phobos as well (such as std.zlib).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653



--- Comment #1 from Vladimir <thecybershadow@gmail.com> 2011-05-13 04:01:57 PDT ---
Created an attachment (id=971)
Memory corruption test

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653



--- Comment #2 from Vladimir <thecybershadow@gmail.com> 2011-05-13 04:03:22 PDT ---
Created an attachment (id=972)
Naive test for disallowing GC interaction after a finalizer exception

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653



--- Comment #3 from Vladimir <thecybershadow@gmail.com> 2011-05-13 04:10:06 PDT ---
https://github.com/D-Programming-Language/phobos/pull/44

https://github.com/D-Programming-Language/druntime/pull/16

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #4 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-05-25 23:00:17 PDT ---
Fixed here: https://github.com/D-Programming-Language/phobos/pull/44 Does that take care of D1 too?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653



--- Comment #5 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-05-26 03:35:29 PDT ---
(In reply to comment #4)
> Fixed here: https://github.com/D-Programming-Language/phobos/pull/44 Does that take care of D1 too?

The Phobos pull request is for D1, the druntime pull request is for D2. Thanks!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653


Sean Kelly <sean@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |sean@invisibleduck.org


--- Comment #6 from Sean Kelly <sean@invisibleduck.org> 2011-06-17 10:54:59 PDT ---
Note that this patch will cause all successive allocations by the process to generate an OOME, since gcx.running will be true forever.  This may be a good stopgap fix, but ultimately the GC has to support allocations inside a finalizer.  The best approach is probably to effectively disable the GC when it's running so an allocating finalizer would simply create a new Pool if no memory was available.  It looks like the collect routine still needs to be rewritten with this in mind, however.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653



--- Comment #7 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-06-18 04:39:19 PDT ---
(In reply to comment #6)
> Note that this patch will cause all successive allocations by the process to generate an OOME, since gcx.running will be true forever.

Yes, this is by design until someone comes up with something better.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5653


Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------