The `disable_provider_free` option of jemalloc cause memory leak

[vinser52]

Environment Information

• UMF version (hash commit or a tag): main branch

Please provide a reproduction of the bug:

When the disable_provider_free option for the jemalloc pool is set it causes memory leaks.

The arena_extent_alloc function:

static void *arena_extent_alloc(extent_hooks_t *extent_hooks, void *new_addr,
                                size_t size, size_t alignment, bool *zero,
                                bool *commit, unsigned arena_ind) {
    (void)extent_hooks; // unused
    (void)arena_ind;    // unused
    umf_result_t ret;

    jemalloc_memory_pool_t *pool = get_pool_by_arena_index(arena_ind);

    void *ptr = new_addr;
    ret = umfMemoryProviderAlloc(pool->provider, size, alignment, &ptr);
    if (ret != UMF_RESULT_SUCCESS) {
        return NULL;
    }

    if (new_addr != NULL && ptr != new_addr) {
        if (!pool->disable_provider_free) {
            umfMemoryProviderFree(pool->provider, ptr, size);
        }
        return NULL;
    }

    ...

    return ptr;
}

So if new_addr != NULL && ptr != new_addr and pool->disable_provider_free are both true the function returns NULL. So the memory returned by the umfMemoryProviderAlloc is never used by the pool and is not returned back to the provider.

How often bug is revealed:

always

Actual behavior:

Memory leaks.

Expected behavior:

No memory leaks

Details

I still want to discuss whether it makes sense to make the free function of the memory provider ops structure optional.

I understand that DEVDAX and file providers do not support free today. But there is no existing pool manager that can work with it. And as mentioned in this bug report we even introduced a memory leak in jemalloc when we tried to make the jemalloc pool work with DEVDAX and file providers.

So I want to raise two related questions:

1. Should any pool manager assume that the memory provider could not support the free operation? If yes, how a pool manager should handle it? As we can see above it is an error-prone approach.
2. Can the DEVDAX and FILE providers be used directly by the pool, or should they always be wrapped with the coarse provider? We already have the coarse provider that solves why not just always wrap DEVDAX and file providers with the coarse provider? We should do it implicitly for the user. And all pool managers would not require special support for the case when memory provider does not support free operation.

Additional information about Priority and Help Requested:

Are you willing to submit a pull request with a proposed change? (Yes, No)

Requested priority: (Showstopper, High, Medium, Low)