Disjoint pool causes memory leak calling umfMemoryProviderFree() with size equal 0

[ldorau]

Disjoint pool causes memory leak calling umfMemoryProviderFree() with size equal 0:

https://github.com/oneapi-src/unified-memory-framework/blob/6fc3e56b4870184dec70613359c4db2ef7f1180a/src/pool/pool_disjoint.cpp#L407

static void memoryProviderFree(umf_memory_provider_handle_t hProvider,
                               void *ptr) {
    auto ret = umfMemoryProviderFree(hProvider, ptr, 0);
    if (ret != UMF_RESULT_SUCCESS) {
        throw MemoryProviderError{ret};
    }
}

what can cause an error (which is ignored now).

Environment Information

• UMF version (hash commit or a tag): 6fc3e56b4870184dec70613359c4db2ef7f1180a

[ldorau]

@igchor @vinser52 @bratpiorka

[vinser52]

More details just FYI. Initially disjoint pool was designed for L0 provider. L0 provider does not need the size when memory is freed (the size parameter is ignored). The similar story is with the OS provider implementation on Windows - the size parameter is ignored when memory is freed.

[igchor]

When we are deallocating Slabs then it's easy, we can just pass the Slab size here: https://github.com/oneapi-src/unified-memory-framework/blob/6fc3e56b4870184dec70613359c4db2ef7f1180a/src/pool/pool_disjoint.cpp#L441

But for allocations that bypass the pooling we do not know the size. Perhaps we could leverage memory tracking there?

[vinser52]

But for allocations that bypass the pooling we do not know the size. Perhaps we could leverage memory tracking there?

Exactly, the plan is to use tracking capabilities. @ldorau already prepared such a fix for the pool_proxy: Red #487.

[ldorau]

@vinser52 @igchor The fix is ready: #490 - please review :-)