Closed vinser52 closed 5 months ago
@vinser52 @igchor @bratpiorka
Furthermore, OS memory provider implementation ignores this fact. When 0 is passed as the size argument to the os_free it ignores the error returned by the os_munmap function if the size is 0.
os_free()
should not ignore this error, but it cannot be changed now, because of the implementation of disjoint pool (see: #481):
https://github.com/oneapi-src/unified-memory-framework/blob/6fc3e56b4870184dec70613359c4db2ef7f1180a/src/pool/pool_disjoint.cpp#L405-L411
and because of the implementation of proxy_free()
of course:
static umf_result_t (void *pool, void *ptr) {
assert(pool);
struct proxy_memory_pool *hPool = (struct proxy_memory_pool *)pool;
return umfMemoryProviderFree(hPool->hProvider, ptr, 0);
}
I propose a fix: #482
The
pool_proxy
implementation is straightforward and simply proxies all allocation/deallocation requests to the underlying memory provider. Theproxy_free()
function just calls theumfMemoryProviderFree()
function which requires thesize
of the allocation as the last argument. Since theproxy_pool
implementation has no any state, the size is unknown and theproxy_free()
function just passes0
as thesize
argument to theumfMemoryProviderFree()
function.Furthermore, OS memory provider implementation ignores this fact. When
0
is passed as thesize
argument to theos_free
it ignores the error returned by theos_munmap
function if thesize
is0
.How often bug is revealed:
always
Details
size
is 0 during deallocation.proxy_pool
should support arbitrary allocations size. Today the size should be multiple of the minimum page size supported by the underlying memory provider. Theproxy_pool
can request the page size during the initialization and automatically round up the size inside theproxy_malloc()
function.