Memory Leak: GC does not deallocate values allocated while it was turned off, unless specifically requested

[Clemapfel]

Hi, the following is a memory leak:

x = 1234
while (true)
    GC.enable(false)
    x = rand()
    GC.enable(true)
    #GC.collect(GC.GC_AUTO)
end

This slowly fills up the RAM until the OS kills the process. With #GC.collect(GC.GC_AUTO) commented in, this code behaves as expected. Without any of the GC. calls, no memory leak occurs either.

Clearly the GC is still updating the roots, otherwise GC.collect would have no effect. For some reason, the unused rand() values are never deallocated. This same behavior is exhibited if implementing the above using the C-API.

Tested on Julia 1.7.2, on Ubuntu 20.04.2 LTS, 64-bit, but I've asked a few people, and they all reproduced it.

I also opened a discourse thread about this

[oscardssmith]

I can reproduce this on master.

[oscardssmith]

I believe what's happening here is that since you disable GC for all the allocations, there are no GC safe points in this code. that said the call to enable GC should introduce a safe point. I'm not sure why it doesn't...

[vtjnash]

If you have any GC.disable calls in your code, the GC may take that as license to not doing GC at all (particularly if all of your code runs with GC disabled as it does in the example)

[oscardssmith]

that doesn't seem right to me since that would make GC.disable unusable.

[Clemapfel]

Even if this was true, why would GC.enable not hint to the GC that I would like it to start working again. If the GC may decide to just not do its job after disabling, then GC.disable is pointless and it would introduce a memory leak anytime it is called

If this is indeed intended behavior, then I would consider that a flaw in the design, or, at the very least, there is missing documentation for GC.enable that explains this behavior

[vchuravy]

Look in the Julia source for calls to maybe_collect those are all the points in the runtime that might cause GC to run. Generally speaking the GC will only check if it is necessary to run before an allocation.

GC.enable/GC.disable are lightweight ways of turning this check on or off, they themselves need not cause the check to occur. So this is very much working as intended.

I believe what's happening here is that since you disable GC for all the allocations, there are no GC safe points in this code.

A safepoint corresponds only to when another thread wants to run GC (and I believe the allocation is still a safepoint)

[Deduction42]

I was able to reproduce this in a top-level script, but putting it in a function stops this endless memory expansion.