https://bugs.kde.org/show_bug.cgi?id=466791
Bug ID: 466791
Summary: Background parser causes crash
Classification: Applications
Product: kdevelop
Version: 5.10.221202
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: Language Support: CPP (Clang-based)
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 156972
--> https://bugs.kde.org/attachment.cgi?id=156972&action=edit
Backtrace from parsing the C++ project
SUMMARY
***
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.
***
STEPS TO REPRODUCE
Note: these steps are only reproducable once the issue already started
happening. As I said in the summary, there were a couple of weeks of normal use
without issues.
1. Make sure the background parser is enabled in the settings.
2. Open an existing project or import a new makefile project.
3. Wait for crash.
OBSERVED RESULT
A segfault appears at different points for different projects, but at roughly
the same point for the same project. But it does not happen at exactly the same
point. And this isn't time based, because with some projects it happens a few
seconds in, with others it keeps going for a full minute or two before kdevelop
crashes.
EXPECTED RESULT
Background parser finishes without causing the crash of the entire IDE.
SOFTWARE/OS VERSIONS
Kernel version: 5.10.167-1-MANJARO
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
ADDITIONAL INFORMATION
I initially added this report to #427147 which seemed to me like it's the same
issue, but I was told that it's a separate issue and I should create a separate
bug report, so here it is.
Here is the output of the console up to the point when this issue appears (I
removed the home directory name and project name for privacy reasons):
***
kdevplatform.serialization: version mismatch or no version hint; expected
version: 84541443
kdevplatform.serialization: "The data-repository at
/home/NAME/.cache/kdevduchain/kdevelop-{57da9fa2-4897-4694-bf10-7e7d8521a133}
has to be cleared."
kf.kio.workers.file: copy()
QUrl("file:///home/NAME/PATH/TO/PROJECT/PROJECT.kdev4") to
QUrl("file:///tmp/kdevelop.knxCDx") mode= -1
kf.kio.workers.file: the file doesn't have any xattr
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevelop.plugins.python.duchain: tuple type object is not available
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevplatform.language: invalid item for index 65 0 0
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
***
I also ran kdevelop with strace as I reproduced the problem. This resulted in a
500MB log, so here are just the last few lines up to the crash:
***
$ tail -n10 kdevelop-strace.log
ioctl(14, FIONREAD, [48]) = 0
read(14, "\t\0\0\0\2\0\0\0\0\0\0\0 \0\0\0kdevelop-strace."..., 48) = 48
poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN},
{fd=25, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=38,
events=POLLIN}, {fd=44, events=POLLIN}, {fd=58, events=POLLIN}, {fd=62,
events=POLLIN}, {fd=69, events=POLLIN}, {fd=74, events=POLLPRI}, {fd=77,
events=POLLIN}, {fd=79, events=POLLIN}], 14, 42) = 1 ([{fd=14,
revents=POLLIN}])
ioctl(14, FIONREAD, [48]) = 0
read(14, "\t\0\0\0\2\0\0\0\0\0\0\0 \0\0\0kdevelop-strace."..., 48) = 48
poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN},
{fd=25, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=38,
events=POLLIN}, {fd=44, events=POLLIN}, {fd=58, events=POLLIN}, {fd=62,
events=POLLIN}, {fd=69, events=POLLIN}, {fd=74, events=POLLPRI}, {fd=77,
events=POLLIN}, {fd=79, events=POLLIN}], 14, 42) = 1 ([{fd=14,
revents=POLLIN}])
ioctl(14, FIONREAD, [48]) = 0
read(14, "\t\0\0\0\2\0\0\0\0\0\0\0 \0\0\0kdevelop-strace."..., 48) = 48
poll([{fd=4, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN},
{fd=25, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=38,
events=POLLIN}, {fd=44, events=POLLIN}, {fd=58, events=POLLIN}, {fd=62,
events=POLLIN}, {fd=69, events=POLLIN}, {fd=74, events=POLLPRI}, {fd=77,
events=POLLIN}, {fd=79, events=POLLIN}], 14, 42 <unfinished ...>) = ?
+++ killed by SIGSEGV (core dumped) +++
***
I ran kdevelop again through GDB and opened the C++ project again. The
backtrace for that is in the attachment.
I was not able to test it with the nightly flatpak build because that one just
hangs without the window ever opening for me, which I think is a separate
issue.
--
You are receiving this mail because:
You are watching all bug changes.
