GC debug fixes

[CyberShadow]

No description provided.

[CyberShadow]

Not sure what's wrong with the rt.lifetime unittests. Ping @rainers @Orvid

[rainers]

AFAICT it's only SENTINEL that needs to be set globally to disable some unittests.

[rainers]

Not sure what's wrong with the rt.lifetime unittests.

I don't see something obvious. Do you have more info on where the tests are failing?

[CyberShadow]

The ones I disabled in 03ab3d6.

[MartinNowak]

• We should restructure those debug tools as wrappers instead of polluting the GC code.
• The code in rt.lifetime is too specifically written for our current GC, maybe we need to move some functionality inside the GC.
• It's possible to use valgrind with gcstub to debug memory corruptions.
• Don't know why debug STOMP doesn't work with struct finalizers.

[CyberShadow]

It's possible to use valgrind with gcstub to debug memory corruptions.

Is there more information about this? I'm currently debugging memory corruption and was thinking about trying Valgrind.

However gcstub won't help find use-after-free bugs in cases where the GC incorrectly collected something.

Don't know why debug STOMP doesn't work with struct finalizers.

The problem is with SENTINEL, not MEMSTOMP, so probably an alignment issue somewhere.

[CyberShadow]

I'm currently debugging memory corruption and was thinking about trying Valgrind.

I've got something working here:

CyberShadow/druntime@pull-20150323-233811-gc-debug...valgrind

[MartinNowak]

Pretty interesting.

[MartinNowak]

However gcstub won't help find use-after-free bugs in cases where the GC incorrectly collected something.

Works, because gcstub never collects, that's a problem on it's own though.

[CyberShadow]

No, that's not the problem I'm talking about.

Say you allocated an object X, and stored the only pointer somewhere the GC can't see it. The GC collects it and allocates a new object at the same address. The code that then attempts to refer to X causes memory corruption.

This is a nontrivial problem even with Valgrind integration. What I'd need to do is make the GC collect objects (and stomp on freed memory), but instead of reusing the memory, keep allocating new memory, so that dangling pointers cause Valgrind errors. Any advice on the easiest way to do this?

[MartinNowak]

Just comment out the cleaning of the free bits.

[MartinNowak]

Somewhere in sweep.
This https://github.com/D-Programming-Language/druntime/blob/95737c0d947fa9096de8e8123440fbc9ba0b9153/src/gc/gc.d#L2196 and that https://github.com/D-Programming-Language/druntime/blob/95737c0d947fa9096de8e8123440fbc9ba0b9153/src/gc/gc.d#L2270.
Probably also the accounting.

[rainers]

Not sure what's wrong with the rt.lifetime unittests.

The runFinalizer functions pass the wrong size to the rt_hasFinalizerInSegment and rt_finalizeFromGC functions. It should be something like this:

            debug(SENTINEL)
                immutable qsize = *sentinel_size(p);
            else
                immutable qsize = size;
            if(!rt_hasFinalizerInSegment(p, qsize, attr, segment))
                continue;

            rt_finalizeFromGC(p, qsize, attr);

(replace p with q for the small object pool).

[rainers]

I think you should restrict the comment to building the unittests, e.g. ".. when building druntime unittests".

[MartinNowak]

Please fixup the finalizer if you find time @CyberShadow.

[CyberShadow]

Sorry, forgot about this pull. Will do.