[stephenjudkins]

This will vary between 32-bit and 64-bit environments. My understanding is that the vastly larger address in 64-bit environments greatly mitigates the chance that data will be mistaken as pointers.

As far as crafting input to match allocated addresses, that is an interesting idea. One could, at the very least, create data that lies within the heap's address range. The issue is, you'd need a lot of data to blacklist a significant amount of memory, and if that's the case why not just DoS with a ton of data?

In practice, a fragmented heap is probably a much bigger issue than actual leaks. As the article points out, a conservative GC cannot perform compaction.

[aaronblohowiak]

I think the key thing that prevents the DOS is that you have to have a 64 bit value that points to the beginning of the allocated block of memory in order for that memory to be kept around -- so, if you malloc 16 bytes are are returned address 100, then a value that contains 101 will not confuse the GC. This has implications if you do some wonky things with only keeping pointers to internal structs and use pointer math to access their containers, but you probably shouldn't do that anyway =D

[barrkel]

Boehm GC has configurable parameters in a header file; you can tell it that interior pointers should be supported.

Interior pointers can be a perfectly reasonable thing to have. For example, many, if not most, implementations of multiple inheritance rely on different values for the 'this' pointer depending on the type of 'this', where that type is somewhere up the inheritance graph. For a class C : public A, public B {}, the physical value of A * = new C and B * = new C will usually be different. The way this is often implemented is by having the addresses of the various vtables for different ancestors stored in the object data, and the conversion from the descendant class to one of the ancestor class returns an interior pointer to one of these vtable locations inside the object data.

[aaronblohowiak]

You are right that I should have added by default.

>The way this is often implemented is by having the addresses of the various vtables for different ancestors stored in the object data, and the conversion from the descendant class to one of the ancestor class returns an interior pointer to one of these vtable locations inside the object data.

Suggests that a pointer value would still exist that would reference the beginning of the allocation block, stored in the vtable so it would still avoid erroneous collection.

Edit: but you are right that there are some valid reasons to have an interior pointer, which is why the GC has the friendly macros.

[barrkel]

No; the vtable normally contains a read-only list of member function pointers, shared across all objects of that type. Objects need to be kept alive solely through the interior pointer to the (compiler-implemented) field (itself a pointer to a vtable) inside the object.

C++ terms:

    class C : public A, public B {};

Typical class layout, in C terms:

    struct A
    {
        // exists assuming virtual methods on A
        // the data this vtable points to is read-only but C++ ctor semantics requires
        // updating vtable pointer during inherited constructor calls
        A_vtable *vtable; 
        // A data
    };
    struct B
    {
        B_vtable *vtable;
    };
    struct C
    {
        C_vtable *vtable; // incorporates A's vtable
        // struct A a; data members of A but without vtable
        struct B b;
    };

A pointer to an instance of C, but typed as B * , will point at the structure contained in C; it will be an interior pointer. There's no reason to expect that there will be another live pointer of type C * pointing to the object; a pointer of type C * needs to be sufficient. Typecasting back down the hierarchy to C * again (with dynamic_cast) will need to adjust the pointer to the start of the object; this normally requires RTTI, and may be done by e.g. storing the offset of the vtable inside the object in the vtable itself (perhaps at a negative offset).

The above is all implementation dependent, of course, but what I've described above maps almost exactly to how Delphi implements COM interfaces (where A would be the base class and B would be a pure virtual class, or interface - no data members).

[aaronblohowiak]

Ah, thank you for taking the time to point that out to me. Very interesting and informative!

[dfox]

On most binary builds of GC i have seen in the wild, interior pointers are enabled (and at least since GC 6.0, this is the default in GC's Makefile)