[Bug 1221183] Upgrade problems with clang-cpp
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c19 --- Comment #19 from Franz Sirl <franz.sirl-obs@lauterbach.com> --- I looked into it a bit and I the crash looks liked this: (gdb) bt #0 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f7fcfd993e5 in __GI_abort () at abort.c:79 #2 0x00007f7fcfdddc27 in __libc_message (action=do_abort, fmt=0x7f7fcff070b8 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x00007f7fcfde5cca in malloc_printerr (str=0x7f7fcff04d8e "free(): invalid pointer") at malloc.c:5347 #4 0x00007f7fcfde7774 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4173 #5 0x00007f7fccf64b69 in llvm::MallocAllocator::Deallocate (this=0x7f7fdac34128 <clang::format::FormatTokenLexer::CSharpAttributeTargets>, Ptr=0x2, Size=140728795303408, Alignment=8) at ../include/llvm/Support/AllocatorBase.h:93 #6 llvm::StringMapEntry<std::nullopt_t>::Destroy<llvm::MallocAllocator> (this=0x2, allocator=...) at ../include/llvm/ADT/StringMapEntry.h:146 #7 llvm::StringMap<std::nullopt_t, llvm::MallocAllocator>::~StringMap (this=0x7f7fdac34128 <clang::format::FormatTokenLexer::CSharpAttributeTargets>) at ../include/llvm/ADT/StringMap.h:186 #8 0x00007f7fcfd9b1be in __cxa_finalize (d=0x7f7fcfd332f0) at cxa_finalize.c:83 #9 0x00007f7fcceb7fd3 in __do_global_dtors_aux () from /usr/lib64/libclang-cpp.so.16 #10 0x00007ffdf9da9380 in ?? () #11 0x00007f7fdad6d9b3 in _dl_fini () at dl-fini.c:138 Backtrace stopped: frame did not save the PC Then I checked the loaded libraries: ds1:~ # ldd /usr/bin/doxygen linux-vdso.so.1 (0x00007ffed7fee000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fee53714000) libclang.so.13 => /usr/lib64/libclang.so.13 (0x00007fee5365f000) libclang-cpp.so.15 => /usr/lib64/libclang-cpp.so.15 (0x00007fee4f8c6000) libLLVM.so.15 => /usr/lib64/libLLVM.so.15 (0x00007fee48d30000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fee48ade000) libm.so.6 => /lib64/libm.so.6 (0x00007fee48990000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fee48963000) libc.so.6 => /lib64/libc.so.6 (0x00007fee4876c000) /lib64/ld-linux-x86-64.so.2 (0x00007fee5377b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fee48767000) libclang-cpp.so.16 => /usr/lib64/libclang-cpp.so.16 (0x00007fee445d7000) libLLVM.so.16 => /usr/lib64/libLLVM.so.16 (0x00007fee3d1d8000) libedit.so.0 => /usr/lib64/libedit.so.0 (0x00007fee3ce00000) librt.so.1 => /lib64/librt.so.1 (0x00007fee3d1cc000) libz.so.1 => /usr/lib64/libz.so.1 (0x00007fee3d1b3000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fee3d184000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fee3cc95000) liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fee3ca00000) Wait? 2 different libclang-cpp and 2 different libLLVM will be loaded? I'm not sure yet who is to blame, but my guess is that at least doxygen should only link directly against libclang-cpp, but not libclang and libLLVM too. I'll look into the doxygen cmake setup and continue investigating. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com