Dear developers, in below codes, the lock data->lock (Line 572) is directly destroyed (Line 632) without releasing before, which is a undefined behaviour, according to the pthread APIs. It's better to release it before destroying it.
|
pthread_mutex_lock(&data->lock); |
|
|
|
// Delete buddy allocator |
|
// If some allocations are still in use, this will fail. |
|
// data->allocator may be NULL if previous destroy() call failed after |
|
// this step. |
|
if (data->allocator != NULL) { |
|
err = buddy_allocator_destroy(&data->allocator); |
|
if (err != AML_SUCCESS) |
|
goto error; |
|
} |
|
|
|
// Unmap memory pools |
|
size_t len; |
|
while ((len = utarray_len(pools)) > 0) { |
|
chunk = *(struct buddy_chunk **)utarray_eltptr(pools, len - 1); |
|
err = aml_area_munmap(data->area, chunk->ptr, chunk->size); |
|
// If munmap() fails here, the allocator is in an inconsistent |
|
// state. It can only be used to be destroyed. |
|
if (err != AML_SUCCESS) |
|
goto error; |
|
utarray_pop_back(pools); |
|
free(chunk); |
|
} |
|
utarray_free(pools); |
|
|
|
// Cleanup top level structure. |
|
pthread_mutex_destroy(&data->lock); |
Dear developers, in below codes, the lock
data->lock(Line 572) is directly destroyed (Line 632) without releasing before, which is a undefined behaviour, according to the pthread APIs. It's better to release it before destroying it.aml/src/allocator/buddy.c
Lines 575 to 602 in e834133