From 39ec64b13d18a17db86f9e93fb2aad5d8faa1f40 Mon Sep 17 00:00:00 2001 From: Sergey Sharybin Date: Tue, 17 Nov 2020 12:45:10 +0100 Subject: Guarded allocator: Add safety around type change While it might not cover all possible abuse of API, it does provide basic checks against most obvious usage mistakes. --- intern/guardedalloc/intern/mallocn.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'intern/guardedalloc') diff --git a/intern/guardedalloc/intern/mallocn.c b/intern/guardedalloc/intern/mallocn.c index bf03fec9b7b..f0dd29a0b9e 100644 --- a/intern/guardedalloc/intern/mallocn.c +++ b/intern/guardedalloc/intern/mallocn.c @@ -96,6 +96,19 @@ void aligned_free(void *ptr) #endif } +/* Perform assert checks on allocator type change. + * + * Helps catching issues (in debug build) caused by an unintended allocator type change when there + * are allocation happenned. */ +static void assert_for_allocator_change(void) +{ + /* NOTE: Assume that there is no "sticky" internal state which would make switching allocator + * type after all allocations are freed unsafe. In fact, it should be safe to change allocator + * type after all blocks has been freed: some regression tests do rely on this property of + * allocators. */ + assert(MEM_get_memory_blocks_in_use() == 0); +} + void MEM_use_lockfree_allocator(void) { /* NOTE: Keep in sync with static initialization of the variables. */ @@ -103,6 +116,8 @@ void MEM_use_lockfree_allocator(void) /* TODO(sergey): Find a way to de-duplicate the logic. Maybe by requiring an explicit call * to guarded allocator initialization at an application startup. */ + assert_for_allocator_change(); + MEM_allocN_len = MEM_lockfree_allocN_len; MEM_freeN = MEM_lockfree_freeN; MEM_dupallocN = MEM_lockfree_dupallocN; @@ -132,6 +147,8 @@ void MEM_use_lockfree_allocator(void) void MEM_use_guarded_allocator(void) { + assert_for_allocator_change(); + MEM_allocN_len = MEM_guarded_allocN_len; MEM_freeN = MEM_guarded_freeN; MEM_dupallocN = MEM_guarded_dupallocN; -- cgit v1.2.3