Turned out that in msan builds, stack frame pointers explicitly returned
by unw_backtrace() in Common/StackTrace.cpp were unpoisened, but stack
frame pointers returned from the same function under the
STD_EXCEPTION_HAS_STACK_TRACE define in std::exception (see (*)) were
not. I tried unpoisoning directly in libcxx. Since this didn't work,
this PR unpoisons where get_stack_trace_frames() is called.
I don't know why this issue never occurred in CI but it fixes #48385 for
me (where msan complains about reads of uninitialized data when query
cache squashes and compresses chunks produced from SELECT last_error_trace
FROM system.errors).
Fixes: #48385
(*) https://github.com/ClickHouse/llvm-project/pull/7/files#diff-8c81d74ef72967be2fa27a31275000aa18532a583490f9673c62d7b981a5b39c
Turned out that in msan builds, stack frame pointers returned by
unw_backtrace()in Common/StackTrace.cpp are unpoisened, but when returned from the same function under the defineSTD_EXCEPTION_HAS_STACK_TRACEinstd::exception(see (*)) they were not. This was not really obvious sincestd::exceptionis in contrib/llvm-project/libcxx. Unposining directly in header "exception" didn't work, therefore this PR unpoisons everywhere whereget_stack_trace_frames()is called.This fixes #48385 for me, i.e. msan complained about reads of uninitialized data when the query cache squashes and compresses chunks produced from
SELECT last_error_trace FROM system.errors SETTINGS allow_experimental_query_cache=1, use_query_cache=1. Actually, the error happened also locally without query cache (then with a different crash stack) - I am not sure why it never occurred in CI.Fixes: #48385
(*) https://github.com/ClickHouse/llvm-project/pull/7/files#diff-8c81d74ef72967be2fa27a31275000aa18532a583490f9673c62d7b981a5b39c
Changelog category (leave one):