clang++ defines GNUC:

$ clang++ -E -dM -xc++ - <<< '' | grep GNUC
#define __GNUC_GNU_INLINE__ 1
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC__ 4

Theoretically it can fail on concurrent unwinding of very long stacks from multiple threads.
But it's Ok.

Is it? 1024 / 32 (our usual stack size limit) = 128 threads getting stack trace simultaneously, and if we're over that, we abort. Combine that with query profiler running on a large server, and it doesn't look good.

In general, the previous code had hard guarantee that the abort() doesn't happen if the program is correct, but this one doesn't. So it will happen.

I have added mmap for buffer and changed total limit to 1024 * 1024 frames

Let's make it complete -- either we shoud mmap enough memory so that the allocation never fails (may be inconvenient to push the server settings here?), or we can add another mmap in case there was not enough memory. If we use the latter option, we should set the initial size low enough, so that this logic is tested. Maybe we can lower the initial size in debug even more.

In case we add second mmap, aborting on its errors looks bad -- i.e. we're out of mappings, several queries fail and start to unwind stack, and then mmap for stack also fails, and we abort. Maybe we can return empty stacks in this case?

Or a third option, simlified -- allocate a static buffer once (maybe slightly larger than 1024 entries), but don't abort if we're out of memory, just truncate the stack. We might see some truncated stacks in profiler from time to time, but this is probably not very important.