SUMMARY Sometimes KDevelop enters a state where it crashes within a few seconds of opening a project. This seems to happen quite often when I'm refactoring large parts of C++ code, so I think it's related to the C++ background parser. Clearing the cache doesn't help, I have to use other editors to finish my code changes before using KDevelop again. In the console KDevelop prints this before crashing: KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kdevelop path = /usr/bin pid = 24966 KCrash: Arguments: /usr/bin/kdevelop KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit sock_file=/run/user/1000/kdeinit5__0 QSocketNotifier: Invalid socket 6 and type 'Read', disabling... QSocketNotifier: Invalid socket 21 and type 'Read', disabling... QSocketNotifier: Invalid socket 29 and type 'Read', disabling... QSocketNotifier: Invalid socket 32 and type 'Read', disabling... QSocketNotifier: Invalid socket 10 and type 'Read', disabling... QSocketNotifier: Invalid socket 80 and type 'Read', disabling... QSocketNotifier: Invalid socket 75 and type 'Exception', disabling... QSocketNotifier: Invalid socket 24 and type 'Read', disabling... QSocketNotifier: Invalid socket 34 and type 'Read', disabling... QSocketNotifier: Invalid socket 65 and type 'Read', disabling... QSocketNotifier: Invalid socket 77 and type 'Read', disabling... QSocketNotifier: Invalid socket 72 and type 'Read', disabling... QSocketNotifier: Invalid socket 41 and type 'Read', disabling... QSocketNotifier: Invalid socket 8 and type 'Read', disabling... QSocketNotifier: Invalid socket 37 and type 'Read', disabling... QSocketNotifier: Invalid socket 9 and type 'Read', disabling... kdevelop.plugins.python.parser: Discarding parts of the code to be parsed because of previous errors SyntaxError: unmatched ']' (<kdev-editor-contents>, line 1) ---- Parsing FAILED ---- LIBCLANG FATAL ERROR: IO failure on output stream: Bad file descriptor Unable to start Dr. Konqi Re-raising signal for core dump handling. Aborted (core dumped) STEPS TO REPRODUCE It's hard to repro, I can provide a tarball of the project that last happened to, but it's too large to attach here. When opening that project in a new KDevelop session it takes longer to crash, I assume it's because the parser needs to reach the point where it crashes. OBSERVED RESULT KDevelop crashes after a few seconds of opening the project SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-48-generic OS Type: 64-bit Processors: 8 × AMD FX(tm)-8320 Eight-Core Processor Memory: 23.5 GiB of RAM
Please attach the backtrace as generated by KCrash. The console output is not useful. Thanks!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Here is my backtrace for that problem: (gdb) bt #0 __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x00007fbfd8e7adf5 in KCrash::defaultCrashHandler(int) () at /lib/x86_64-linux-gnu/libKF5Crash.so.5 #2 0x00007fbfd7683950 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6 #3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #4 0x00007fbfd7668864 in __GI_abort () at abort.c:79 #5 0x00007fbf9a4383a1 in aborting_fatal_error_handler() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/tools/libclang/FatalErrorHandler.cpp:18 #6 0x00007fbf95f9a034 in llvm::report_fatal_error(llvm::Twine const&, bool) () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #7 0x00007fbf95f9a100 in llvm::report_fatal_error(llvm::StringRef, bool) () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #8 0x00007fbf9601ed3b in () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #9 0x00007fbf9601edc9 in llvm::raw_fd_ostream::~raw_fd_ostream() () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #10 0x00007fbf9a8a6370 in operator() () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:85 #11 ~unique_ptr () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:361 #12 ~PrecompilePreambleConsumer () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/PrecompiledPreamble.cpp:157 #13 ~PrecompilePreambleConsumer() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/PrecompiledPreamble.cpp:157 #14 0x00007fbf9a8a281e in operator() () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:85 #15 ~unique_ptr () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:361 #16 _Destroy<std::unique_ptr<clang::ASTConsumer, std::default_delete<clang::ASTConsumer> > > () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_construct.h:140 #17 __destroy<std::unique_ptr<clang::ASTConsumer, std::default_delete<clang::ASTConsumer> >*> () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_construct.h:152 #18 _Destroy<std::unique_ptr<clang::ASTConsumer, std::default_delete<clang::ASTConsumer> >*> () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_construct.h:184 #19 _Destroy<std::unique_ptr<clang::ASTConsumer, std::default_delete<clang::ASTConsumer> >*, std::unique_ptr<clang::ASTConsumer, std::default_delete<clang::ASTConsumer> > > () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/alloc_traits.h:738 #20 ~vector () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:680 #21 ~MultiplexConsumer () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/MultiplexConsumer.cpp:261 #22 ~MultiplexConsumer() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/MultiplexConsumer.cpp:261 #23 0x00007fbf9a83c641 in operator() () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:85 #24 reset () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:182 #25 operator= () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:167 #26 operator= () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:212 #27 operator= () at /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:371 #28 setASTConsumer() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/CompilerInstance.cpp:124 #29 0x00007fbf9a88ad4c in EndSourceFile() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/FrontendAction.cpp:982 #30 0x00007fbf9a8a3dae in Build() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/PrecompiledPreamble.cpp:361 #31 0x00007fbf9a828e35 in getMainBufferWithPrecompiledPreamble() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/ASTUnit.cpp:1378 #32 0x00007fbf9a82bc63 in Reparse() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/lib/Frontend/ASTUnit.cpp:1857 #33 0x00007fbf9a414016 in clang_reparseTranslationUnit_Impl () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/tools/libclang/CIndex.cpp:4153 #34 operator() () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/tools/libclang/CIndex.cpp:4174 #35 callback_fn<(lambda at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/clang/tools/libclang/CIndex.cpp:4173:37)>(void) () at /build/llvm-toolchain-10-tSxQo1/llvm-toolchain-10-10.0.1/llvm/include/llvm/ADT/STLExtras.h:108 #36 0x00007fbf95f902e7 in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #37 0x00007fbf95f90404 in () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #38 0x00007fbf9603c94a in () at /usr/lib/llvm-10/lib/../lib/libLLVM-10.so.1 #39 0x00007fbfd4d61590 in start_thread (arg=0x7fbed4a99640) at pthread_create.c:463 #40 0x00007fbfd775b223 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Created attachment 135053 [details] The backtrace in a file I put a more complete backtrace in that file
I observe the same behavior. After I installed KDevelop (on Manjaro from the official repo, version 5.10.221202), it worked for a couple weeks, then it started crashing. Reinstalling did not help. Deleting everything containing the string "kdev" in the file or folder name within the home directory, including all subdirectories, did not help. However installing the flatpak (from flathub) did help, again only for a few weeks. Then out of nowhere I started getting the same kind of crash again, always at 13-14% according to the progress bar on the bottom right. Reinstalling the flatpak and deleting all the aforementioned files did not help. Reinstalling the version from the repo did not help either. Then I tried opening another project. One that was in fact not a C++ project, but php/python. KDevelop crashed again while parsing, this time at about 70% (sometimes a few more, sometimes less). It seems that at some point something "snaps", and the issue just keeps happening regularly, and in more than one project. Disabling the background parser in the settings stops the crashes.
Created attachment 156945 [details] Backtrace My backtrace running the version from the manjaro repo (version 5.10.221202)
@anonymous11oneeleven@gmail.com, please take your issue to a different report -- it is not the same issue, and 80% of issues are with the background parser, they can not all be tracked in the same repot. Thanks. :) @Mattia Basaglia Sorry for not replying any more after you posted the backtrace, I overlooked it. The libclang you had the issue with is 5 versions old, if you are still using KDevelop, does it still happen with the current libclang?
changing status
(In reply to Sven Brauch from comment #8) > @Mattia Basaglia Sorry for not replying any more after you posted the > backtrace, I overlooked it. The libclang you had the issue with is 5 > versions old, if you are still using KDevelop, does it still happen with the > current libclang? I have had some crashes recently but didn't get a backtrace for them.