Memory leak issue between extern (c) and D function

Guillaume Piolat first.last at spam.org
Sun Apr 16 23:33:25 UTC 2023


On Friday, 14 April 2023 at 17:31:02 UTC, backtrack wrote:
> however the memory is not releasing.

With the D GC, your object can have three state:

   - reachable by GC. If D code can see the reference, then it's 
"alive", kept alive by GC scanning. The GC finds the reference 
and doesn't touch it. This is the invariant that you need to 
maintain when interacting with C.

   - unreachable by GC and thus at a risk of being reclaimable at 
next GC collect.
     This happens when all your references are null.
     If you want immediate destructor, call .destroy() before 
nulling your references so that the object can't be scanned. By 
calling destroy() on all your objects manually, you can reach 
destruction determinism.

   - non-existing, memory has been reclaimed. You don't 
necessarily need to do that with __delete, this should be very 
rare even. If the references to the object are null, then their 
destructor will eventually be called if it wasn't already with 
.destroy, the memory eventually reclaimed. Usually you don't need 
to care about that state.



More information about the Digitalmars-d-learn mailing list