Bug 427147

Summary: Often the background parser causes crashes
Product: [Applications] kdevelop Reporter: Mattia Basaglia <glax>
Component: Language Support: CPP (Clang-based)Assignee: kdevelop-bugs-null
Status: RESOLVED WORKSFORME    
Severity: normal CC: anonymous11oneeleven, deadmaxfr, mail
Priority: NOR    
Version First Reported In: 5.5.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: The backtrace in a file
Backtrace

Description Mattia Basaglia 2020-09-30 12:04:40 UTC
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
Comment 1 Sven Brauch 2020-09-30 17:03:14 UTC
Please attach the backtrace as generated by KCrash. The console output is not useful. Thanks!
Comment 2 Bug Janitor Service 2020-10-15 04:33:15 UTC
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!
Comment 3 Bug Janitor Service 2020-10-30 04:33:29 UTC
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!
Comment 4 Alexandre Martins 2021-01-22 07:42:52 UTC
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
Comment 5 Alexandre Martins 2021-01-22 07:54:12 UTC
Created attachment 135053 [details]
The backtrace in a file

I put a more complete backtrace in that file
Comment 6 anonymous11oneeleven 2023-03-03 06:10:28 UTC
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.
Comment 7 anonymous11oneeleven 2023-03-03 06:12:47 UTC
Created attachment 156945 [details]
Backtrace

My backtrace running the version from the manjaro repo (version 5.10.221202)
Comment 8 Sven Brauch 2023-03-03 07:29:03 UTC
@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?
Comment 9 Sven Brauch 2023-03-03 07:29:22 UTC
changing status
Comment 10 Mattia Basaglia 2023-03-03 08:00:02 UTC
(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.
Comment 11 Bug Janitor Service 2023-03-18 03:45:43 UTC
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!
Comment 12 Bug Janitor Service 2023-04-02 03:45:23 UTC
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!