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

           Summary: GC infinite loop when invalid user code runs.
           Product: D
           Version: 1.014
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: davidl@126.com


class weirdclass
{
        void func()
        {
                delete this;
        }
}

void main()
{
        auto inst=new weirdclass;
        inst.func;
        delete inst;   // GC loops here
}

If I read disassembly correctly:

it loops in phobos code gcx.d

        // Mark each free entry, so it doesn't get scanned
        for (n = 0; n < B_PAGE; n++)
        {
            for (List *list = bucket[n]; list; list = list.next)  // loops here
            {
                pool = findPool(list);
                assert(pool);
                pool.freebits.set(cast(uint)(cast(byte *)list - pool.baseAddr)
/ 16);
            }
        }

Though i didn't recompile phobos to confirm this.


-- 

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





------- Comment #1 from braddr@puremagic.com  2007-09-17 23:19 -------
double delete == undefined behavior.  Anything that happens after that point is fair game.


-- 

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





------- Comment #2 from shro8822@vandals.uidaho.edu  2007-09-17 23:59 -------
yes, but a clean crash (or even a seg-v) would be much better


-- 

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





------- Comment #3 from braddr@puremagic.com  2007-09-18 00:38 -------
Actually, the more interesting part of this that actually should be considered a bug... from the spec on part of what delete does:

The pointer, dynamic array, or reference is set to null after the delete is performed.

The question I have is:  should inst have been set to null since it's the underlying storage for 'this'?

If it had been, then the second delete would have been a safe no-op.


-- 

d-bugmail@puremagic.com wrote:
> ------- Comment #3 from braddr@puremagic.com  2007-09-18 00:38 -------
> Actually, the more interesting part of this that actually should be considered
> a bug... from the spec on part of what delete does:
> 
> The pointer, dynamic array, or reference is set to null after the delete is
> performed.
> 
> The question I have is:  should inst have been set to null since it's the
> underlying storage for 'this'?

Within the context of weirdclass.func, 'this' is basically a local variable, and it is likely set to null when 'delete this' is called. However, I'm not sure it's reasonable to assert that all references to the object should be set to null when the object is deleted.  What if weirdclass.func() were defined in a library and the code weren't available for inspection when evaluating main()?

As for the endless loop, I'm not sure there's an efficient way to fix the problem.  When gc_free(p) is called, if p is non-null and points to the head of a memory block owned by the GC, the block is added to the free list.  In this case, since the block is already on the free list it ends up becoming a list of one element which points to itself.

To fix this, the GC would have to check for the presence of p on the free list before adding it, which is an O(N) operation.  If any change were to be made, it should only occur in a debug build of the GC, and an exception should be thrown if a double delete is detected.  And for what it's worth, I think the GC does offer features like this when built with debug=LOGGING.

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





------- Comment #5 from davidl@126.com  2007-09-19 02:10 -------
it's related to the compiling command of phobos
when DFLAGS in src\phobos\win32.mak contains -O this bug is triggered.

with non optimized phobos, the following code on DMD 1.021 behaves correctly with printing : "exception caught"

class weirdclass
{
        void func()
        {
                delete this;
        }
}

void main()
{
        auto inst=new weirdclass;
        inst.func;
                try
                {
                delete inst;   // GC loops here
                }
                catch(Object o)
                {
                        printf("exception caught");
                }
}


-- 

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





------- Comment #6 from davidl@126.com  2007-09-19 02:30 -------
oops, it's not related to optimization.
it's the most weird bug in the world, it's related to -unittest.
once compiling your phobos with -unittest , the app goes all ok, and fine.
once compiling your phobos without -unittest, the app loops


-- 

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





------- Comment #7 from davidl@126.com  2007-09-19 02:54 -------
I don't know if the following is the sane check. But this prevent the GC from
looping in this case.
add to phobos\internal\gc\gcx.d
line 1570:

                if(list is list.next)
                {
                        throw new Exception("looping while we try to free the
list!");
                }


-- 

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





------- Comment #8 from davidl@126.com  2007-09-19 03:03 -------
tango doesn't have such problem. So there must be better solution


-- 

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


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #9 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-24 23:22:00 PDT ---
2.053:
object.Error: Access Violation
----------------
40D554
40D3CB
----------------

I guess that means fixed?

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