www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1512] New: GC infinite loop when invalid user code runs.

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


--
Sep 17 2007
next sibling parent d-bugmail puremagic.com writes:
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.


--
Sep 17 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--
Sep 17 2007
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
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.


--
Sep 17 2007
parent Sean Kelly <sean f4.ca> writes:
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.
Sep 18 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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");     
                }
}


--
Sep 19 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--
Sep 19 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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!");
                }


--
Sep 19 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--
Sep 19 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1512


safety0ff.bugz <safety0ff.bugz gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |safety0ff.bugz gmail.com


--- Comment #10 from safety0ff.bugz <safety0ff.bugz gmail.com> 2013-10-31
02:25:49 PDT ---
Works for me, recent versions of DMD, LDC give: Error: Cannot modify 'this'
inside func.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 31 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1512



--- Comment #11 from safety0ff.bugz <safety0ff.bugz gmail.com> 2013-10-31
02:34:55 PDT ---
(In reply to comment #10)

 Works for me, recent versions of DMD, LDC give: Error: Cannot modify 'this'
 inside func.


For D2, probably still valid for D1 (what it is marked as.)

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