Guardedalloc: detection of invalid calls to `MEM_freeN` on data created with `new` or `MEM_new`

Announcements
1

Commit 06be295946a in main branch introduces a new check in our guarded allocator library. It ensures that no data created the ‘C++ way’ using the (guarded-overridden) new operator or the MEM_new utils, is freed by a call to MEM_freeN (and other related ‘C type’ memory management, like dupalloc or re(c)alloc).

Invalid cases will print an error message in the console (like e.g. Attempt to use C-style MEM_freeN on a pointer created with CPP-style MEM_new or new), and abort in case Blender is built with WITH_ASSERT_ABORT. If you encounter such case, please fix it or report it.

A lot of invalid cases have been fixed in the past few days already in Blender code, but there are likely some less easily triggered ones still there.

More information can also be found in the PR !123740.

Hints to Fix Reported Errors

In a lot cases, issues are caused by usage of C++-style MEM_new allocation on data passed to some C-style generic callback as a void * pointer. This happens a lot in the UI code e.g., with arguments like void *argN. These are systematically freed with MEM_freeN. Most of the time, the allocated data is actually trivial, and can be created with MEM_cnew instead.

11 Likes
2

Two follow-up notes:

  • When building with ASAN, invalid calls to MEM_freeN on C++ created data will now use ASAN to also display the backtrace of the memory block allocation (4195e9e1a7). This makes complex error cases way easier to investigate.
  • A design task has been created, to improve the (currently confusing and potentially bad) handling of the MEM_guardedalloc code with the C++ new/delete operations.
1 Like