-
Notifications
You must be signed in to change notification settings - Fork 3
Closed
Description
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.
Lines 575 to 602 in e834133
| 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); |
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels