Re: seawasp failing, maybe in glibc allocator

On Wed, May 19, 2021 at 5:02 AM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> It seems that the upload of the valgrind run (many hours…) failed on "413
> request entity too large", and everything seems to have been cleaned
> despite the "--keepall" I think I put when I started the run.

I installed Clang/LLVM version
"1:13~++20210520071732+02f2d739e074-1~exp1~20210520052519.57" from
https://apt.llvm.org/ on a Debian buster box, and I saw that
contrib/ltree's test fail about half the time with a range of weird
and wonderful outputs (wrong answers) similar to seawasp, but it never
crashed. I ran it under valgrind and I managed to get:

==529250== Invalid read of size 8
==529250== at 0x1475B6CA: void
std::vector<llvm::orc::SymbolStringPtr,
std::allocator<llvm::orc::SymbolStringPtr>
>::_M_realloc_insert<llvm::orc::SymbolStringPtr
const&>(__gnu_cxx::__normal_iterator<llvm::orc::SymbolStringPtr*,
std::vector<llvm::orc::SymbolStringPtr,
std::allocator<llvm::orc::SymbolStringPtr> > >,
llvm::orc::SymbolStringPtr const&) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x1474F246:
llvm::orc::JITDylib::removeTracker(llvm::orc::ResourceTracker&) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x14741E0A:
llvm::orc::ExecutionSession::removeResourceTracker(llvm::orc::ResourceTracker&)
(in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x14747421: llvm::orc::JITDylib::clear() (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x14751F5B: llvm::orc::ExecutionSession::endSession()
(in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x14785207: llvm::orc::LLJIT::~LLJIT() (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x147A4C7D: LLVMOrcDisposeLLJIT (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x124D0094: llvm_shutdown (llvmjit.c:892)
==529250== by 0x57BC08: proc_exit_prepare (ipc.c:209)
==529250== by 0x57BC77: proc_exit (ipc.c:107)
==529250== by 0x5A545B: PostgresMain (postgres.c:4700)
==529250== by 0x517569: BackendRun (postmaster.c:4491)
==529250== by 0x517569: BackendStartup (postmaster.c:4213)
==529250== by 0x517569: ServerLoop (postmaster.c:1745)
==529250== Address 0x1a969088 is 1,416 bytes inside a block of size
3,072 free'd
==529250== at 0x4839EAB: operator delete(void*) (vg_replace_malloc.c:584)
==529250== by 0x141DFD8E: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x141DD9C0: llvm::LazyValueInfo::releaseMemory() (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13294832:
llvm::PMDataManager::freePass(llvm::Pass*, llvm::StringRef,
llvm::PassDebuggingString) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13294774:
llvm::PMDataManager::removeDeadPasses(llvm::Pass*, llvm::StringRef,
llvm::PassDebuggingString) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13290A69:
llvm::FPPassManager::runOnFunction(llvm::Function&) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x14137632: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13290FDE:
llvm::legacy::PassManagerImpl::run(llvm::Module&) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x131F8625: LLVMRunPassManager (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x124D0772: llvm_optimize_module (llvmjit.c:620)
==529250== by 0x124D0772: llvm_compile_module (llvmjit.c:671)
==529250== by 0x124D0772: llvm_get_function (llvmjit.c:291)
==529250== by 0x124DA3BC: ExecRunCompiledExpr (llvmjit_expr.c:2402)
==529250== by 0x41D15C: ExecEvalExprSwitchContext (executor.h:339)
==529250== by 0x41D15C: ExecQual (executor.h:408)
==529250== by 0x41D15C: ExecScan (execScan.c:227)
==529250== Block was alloc'd at
==529250== at 0x4838DEF: operator new(unsigned long)
(vg_replace_malloc.c:342)
==529250== by 0x141E47D6: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x141E43B7: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x141E3202: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x141E0501: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x141DDD74: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x141DDC4C:
llvm::LazyValueInfo::getConstant(llvm::Value*, llvm::Instruction*) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13D0EE4B: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13D11D42: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x1329098C:
llvm::FPPassManager::runOnFunction(llvm::Function&) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x14137632: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250== by 0x13290FDE:
llvm::legacy::PassManagerImpl::run(llvm::Module&) (in
/usr/lib/x86_64-linux-gnu/libLLVM-13.so.1)
==529250==

Maybe they should rewrite LLVM in Rust.