You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
Hello,
I'm getting systematically a SIGSEV when I run rdm built with LLVM-12.
To Reproduce
I simply build and run rdm.
During rdm build I had the following output from CMake:
...
-- Detecting CXX compile features - done
-- llvm-config executable found: /usr/local/llvm/bin/llvm-config
-- Using Clang version 12.0.1 from /usr/local/llvm/lib with CXXFLAGS -I/usr/local/llvm/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-- Found LibClang: /usr/local/llvm/lib/libclang.so
...
Expected behavior
Server should run without crashing.
Backtrace
With GDB:
(gdb) r
+r
Starting program: /ebs/frperies/repo/rtags/build/bin/rdm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#1}::operator()() const (this=0x0) at /usr/local/gcc-10.3.0/include/c++/10.3.0/mutex:717
717 std::__invoke(std::forward<_Callable>(__f),
(gdb) bt
#0 std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#1}::operator()() const (this=0x0) at /usr/local/gcc-10.3.0/include/c++/10.3.0/mutex:717
#1 std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#2}::operator()() const (this=0x0) at /usr/local/gcc-10.3.0/include/c++/10.3.0/mutex:722
#2 std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#2}::_FUN() () at /usr/local/gcc-10.3.0/include/c++/10.3.0/mutex:722
#3 0x00007ffff5dd520b in __pthread_once_slow () from /lib64/libpthread.so.0
#4 0x00007fffef1c8c2b in llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const () from /usr/local/llvm/lib/../lib/libLLVM-12.so
#5 0x00007fffef16c512 in llvm::cl::OptionCategory::registerCategory() () from /usr/local/llvm/lib/../lib/libLLVM-12.so
#6 0x00007fffef05345c in __static_initialization_and_destruction_0(int, int) [clone .constprop.0] () from /usr/local/llvm/lib/../lib/libLLVM-12.so
#7 0x00007ffff7dea9c3 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7ddc17a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9 0x0000000000000001 in ?? ()
#10 0x00007fffffffcb55 in ?? ()
#11 0x0000000000000000 in ?? ()
As suggested from another similar issue, I did a run with valgrind:
$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ~/bin/rdm
==27316== Memcheck, a memory error detector
==27316== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27316== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==27316== Command: /ebs/frperies/bin/rdm
==27316==
==27316== Invalid read of size 8
==27316== at 0x6025C2: std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#2}::_FUN() (invoke.h:60)
==27316== by 0x69F020A: __pthread_once_slow (in /usr/lib64/libpthread-2.17.so)
==27316== by 0x89DCC2A: llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const (in /usr/local/llvm/lib/libLLVM-12.so)
==27316== by 0x8980511: llvm::cl::OptionCategory::registerCategory() (in /usr/local/llvm/lib/libLLVM-12.so)
==27316== by 0x886745B: __static_initialization_and_destruction_0(int, int) [clone .constprop.0] (in /usr/local/llvm/lib/libLLVM-12.so)
==27316== by 0x400F9C2: _dl_init (in /usr/lib64/ld-2.17.so)
==27316== by 0x4001179: ??? (in /usr/lib64/ld-2.17.so)
==27316== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==27316==
==27316==
==27316== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==27316== Access not within mapped region at address 0x0
==27316== at 0x6025C2: std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#2}::_FUN() (invoke.h:60)
==27316== by 0x69F020A: __pthread_once_slow (in /usr/lib64/libpthread-2.17.so)
==27316== by 0x89DCC2A: llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const (in /usr/local/llvm/lib/libLLVM-12.so)
==27316== by 0x8980511: llvm::cl::OptionCategory::registerCategory() (in /usr/local/llvm/lib/libLLVM-12.so)
==27316== by 0x886745B: __static_initialization_and_destruction_0(int, int) [clone .constprop.0] (in /usr/local/llvm/lib/libLLVM-12.so)
==27316== by 0x400F9C2: _dl_init (in /usr/lib64/ld-2.17.so)
==27316== by 0x4001179: ??? (in /usr/lib64/ld-2.17.so)
==27316== If you believe this happened as a result of a stack
==27316== overflow in your program's main thread (unlikely but
==27316== possible), you can try to increase the size of the
==27316== main thread stack using the --main-stacksize= flag.
==27316== The main thread stack size used in this run was 8388608.
==27316==
==27316== FILE DESCRIPTORS: 3 open (3 std) at exit.
==27316==
==27316== HEAP SUMMARY:
==27316== in use at exit: 0 bytes in 0 blocks
==27316== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==27316==
==27316== All heap blocks were freed -- no leaks are possible
==27316==
==27316== For lists of detected and suppressed errors, rerun with: -s
==27316== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
It looks a read of size 8 is done at adress 0x0.
Environment
OS/Version: CentOs
RTags(rdm,rc): 2.33
Emacs: 28.1
LLVM/Clang: 12.01
Thank you for your support.
The text was updated successfully, but these errors were encountered:
I think this is an ongoing issue as rtags seems to be currently mostly unmaintained. @Andersbakken is there any chance to get rtags back on track for more recent LLVM releases? It is a massively useful tool and in my experience much faster and leaner than LSP. So it would be nice to have it work correctly again. I tried to have a look but am not experienced enough with LLVM / clang to understand what's going on.
Description
Hello,
I'm getting systematically a SIGSEV when I run rdm built with LLVM-12.
To Reproduce
I simply build and run rdm.
During rdm build I had the following output from CMake:
Expected behavior
Server should run without crashing.
Backtrace
With GDB:
As suggested from another similar issue, I did a run with valgrind:
It looks a read of size 8 is done at adress 0x0.
Environment
Thank you for your support.
The text was updated successfully, but these errors were encountered: