cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
search
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

We value your input!
Please participate in Archicad 28 Home Screen and Tooltips/Quick Tutorials survey

Take our survey

New memory allocator in Archicad 28

Since version 28, Archicad uses a custom memory allocator (TBB) on Windows instead of the system default. This change can cause new memory-related bugs if allocators are used inconsistently, such as freeing memory allocated by the system allocator with TBB or the other way around, leading to crashes.


Symptoms of inconsistent memory handling:

  • Crashes in tbbmalloc.dll or ucrtbase.dll when freeing or reallocating memory. The memory address passed to the crashing operation is usually the memory that was handled inconsistently.
  • The crash might not be deterministic as the inconsistently used free operation is not guaranteed to crash. Often, it only results in a memory leak instead of a fatal error.
  • Turn on ProtectedAlloc to reliably detect inconsistent allocator use and other memory-related problems. Set "Computer\HKEY_CURRENT_USER\SOFTWARE\GRAPHISOFT\Debug\GSRoot\MemoryManager\useProtectedAlloc" REG_DWORD type registry value from the default 0 to 1. (Using protected alloc significantly slows down Archicad and increases memory use.) *
  • Crashes occur only on Windows.
  • Crashes disappear when using the system allocator. Change "Computer\HKEY_CURRENT_USER\SOFTWARE\GRAPHISOFT\Debug\GSRoot\MemoryManager\memoryManagerType" REG_SZ type registry value from the default 0 to 2 (System) to force using the system allocator. This way, the inconsistent allocator use can’t happen. If the crash disappears with this setting, it was likely caused by inconsistent allocator use. *

*Don't forget to restore debug registry values to their default values before final testing.

 

Fixing the problem:

  • Include "Support/Modules/GSRoot/GSMalloc.hpp" and "Support/Modules/GSRoot/GSNew.hpp" in all your Add-On module translation units (e.g., via force include or precompiled headers) to use Archicad’s custom allocator. This will override all memory operations (new/delete, malloc/free, etc.) in the module to use Archicad’s custom allocator.
  • The above headers are already added to the Add-On module precompiled header if you use the latest version of the Archicad Add-On CMake template (https://github.com/GRAPHISOFT/archicad-addon-cmake)
  • If your Add-On consists of multiple modules, all other modules should also use the above-precompiled header settings and link to GSRootImp.lib.
  • 3rd party binary libraries you can’t rebuild with the above settings might also cause allocation inconsistency problems if they expose memory allocations, i.e., if the library interface is designed in a way that the caller needs to free library-allocated memory or the library frees caller-allocated memory. Possible workarounds are:
    • Many libraries allow the caller to customize their memory allocation and deallocation operations. To guarantee consistent allocator use, redirect memory allocation and deallocation to the GSRoot-provided malloc and free.
    • Wrap the 3rd party library in a wrapper module. The module should provide an interface that doesn’t expose the library’s or its memory allocations to the rest of your Add-On. Please don’t use any Archicad DevKit headers from this wrapper module, and don’t link it to DevKit modules. This way, both the wrapper and the wrapped module will use the system-provided allocator on Windows.

Please let us know in the forum if you need help.

 

Happy bug hunting,

Akos