Value proposition: ClickHouse sends us error messages with stacktrace information. Ideally we would parse this stacktrace information into actual stacktraces. Here is an integration for exactly that. The testcase is ripped straight from https://sentry.io/organizations/sentry/issues/856036064

ClickHouse calls backtrace_symbols. It already returns a formatted string/list of strings. ClickHouse then parses this string and replaces symbols with demangled versions. I didn't bother with parsing addresses and offsets as I don't see much value in that information (not sure if it's used in grouping) and some of those return addresses (brackets at the end) seem wrong:

23. clickhouse-server() [0xa3c68cf]
24. /lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7fdb108c5184]
25. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fdb0fee003d]

I'm open to alternative naming suggestions. As far as I can tell this function has its origins in glibc. LibExecInfoBacktraceIntegration seemed bulky. Perhaps GlibcBacktraceIntegration to avoid conflict with GDB's output format, which seems entirely different? I'm generally unsure of backtrace_symbols's origin. It seems to have started as a glibc thing but there are ports for BSD and Darwin. It isn't POSIX though.

When discussing the idea of this with @mitsuhiko there was the idea to have a single NativeStacktraceIntegration where we would add new kinds of stacktrace formats over time. However, in order to not break grouping between minor versions, we can't actually add new variants to that "super-integration" without having the user explicitly opt into each of them (just the same reason why we can't make this a default integration). Therefore I see no point in having one integration for multiple formats, and the naming problem persists.

cc @alex-hofsteede