I am trying to develop an out-of-tree plugin that works with clang-tidy-10 on Ubuntu 20.04. I understand and have verified that this is now possible with the -load option since version 14, but admin installed version is out of my control and it would be much easier for adoption if I don’t have to distribute a duplicate binary.
While never officially supported, the LD_PRELOAD trick should work due to the constructor-based check register mechanism, and reportedly worked once upon a time as per this slide (circa 2017 ~LLVM 4.0, code).
This works fine when built against a full checkout at llvmorg-10.0.0 and preloaded to the custom-built clang-tidy binary. However, when I try to build against the system LLVM 10.0.0 dev packages then LD_PRELOAD to the system clang-tidy, I got
#0 0x00007ff7fdbeb4ff llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/llvm-10/lib/libLLVM-10.so.1+0x9814ff)
#1 0x00007ff7fdbe97b0 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-10/lib/libLLVM-10.so.1+0x97f7b0)
#2 0x00007ff7fdbebac5 (/usr/lib/llvm-10/lib/libLLVM-10.so.1+0x981ac5)
#3 0x00007ff8043ba420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x00007ff7fcdc4722 free /build/glibc-SzIz7B/glibc-2.31/malloc/malloc.c:3124:12
#5 0x00007ff8020bc850 (/usr/lib/llvm-10/lib/libclang-cpp.so.10+0x7be850)
#6 0x00007ff7fcd70fde __cxa_finalize /build/glibc-SzIz7B/glibc-2.31/stdlib/cxa_finalize.c:84:6
#7 0x00007ff802055dc7 (/usr/lib/llvm-10/lib/libclang-cpp.so.10+0x757dc7)
Segmentation fault (core dumped)
and on some other occasions
munmap_chunk(): invalid pointer
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
and the new checks does not get registered either.
It smells to me like memory corruption due to race conditions in a destructor, but there seems to be no strange rpath or doubly linked libLLVM as far as I could check. Any idea how and why this could be happening?