`ps/Profiler.cpp` counts the number of allocations by overriding `malloc`, `calloc` and `realloc` with an increment. The allocation is done by the actual functions via `dlsym`. However, there might be a call that will be in limbo without having a statically allocated buffer that can be used during the whole bootstrapping process. This is where `static char alloc_bootstrap_buffer[32];` comes in. At the time, the first `malloc` was requesting 32 or lessCounting allocations required some ugly code platform-specific code that needs several workarounds and hacks to properly function. HoweverMoreover, currentlyon linux, its requesting 252 via `calloc`.the overriden memory functions have to statically allocate some memory to be able to bootstrap itself which is dependent on dlsym code, Here is the stackand prone to breakage.
```
#0 calloc (nm=1, sz=252) at ../../../source/ps/Profile.cpp:591
#1 0x00007ffff2375562 in g_malloc0 () from /usr/lib/libglib-2.0.so.0
#2 0x00007ffff238b683 in ?? () from /usr/lib/libglib-2.0.so.0
#3 0x00007ffff238cd17 in g_slice_alloc () from /usr/lib/libglib-2.0.so.0
#4 0x00007ffff2359403 in g_hash_table_new_full () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff2375464 in ?? () from /usr/lib/libglib-2.0.so.0
#6 0x00007ffff23340c9 in ?? () from /usr/lib/libglib-2.0.so.0
#7 0x00007ffff7fcbede in call_init () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7fcbfcc in _dl_init () from /lib64/ld-linux-x86-64.so.2
#9 0x00007ffff7fe396a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ??Since, ()
#11 0x00007fffffffe02d in ??allocations are only counted on debug builds, ()
#12 0x0000000000000000 in ??not really useful and much better tools for debugging already exists, ()
```
Tthis number has been updated several times already.
Error observed with `glibc 2.35`code is now removed.