[Issue 1512] GC infinite loop when invalid user code runs.

[Sean Kelly]

d-bugmail at puremagic.com wrote:
> ------- Comment #3 from braddr at 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.