[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #4 from Igor Kushnir --- > >How should non-KDE, pure-Qt, single-instance applications request focus on > >second instance launch to get it in all Plasma versions? > > Pass the startup ID to the second instance. See QX11Info::setNextStartupId() > then calling activate will "just work" 1. When an application is launched from terminal, it gets an empty QX11Info::nextStartupId(). So this simple implementation can't work as well as KDE applications in this case. 2. Even when I pass a nonempty QX11Info::nextStartupId() from the secondary instance, then pass it to QX11Info::setNextStartupId() in the primary instance, then activate the primary instance's main window, it still doesn't get focus if it is not minimized/hidden. So I haven't noticed any effect of the simple implementation. I use QtSingleApplication to pass messages between instances. Code that runs in the primary instance: QByteArray startupId = QByteArray::fromBase64(receivedBase64EncodedId); qCritical() << startupId; QX11Info::setNextStartupId(startupId); qApp->setActiveWindow(this); raise(); activateWindow(); A typical received id in a KDE neon VM is "KDE-neon-VM;1551168703;784674;950_TIME254792". I tried removing the "qApp->setActiveWindow(this)" line, reordering "raise()" and "activateWindow()" lines; setting StartupNotify both to true and false in the application desktop file. But nothing makes a difference. Does the secondary instance have to explicitly send the "remove" message to end the launch sequence as described in https://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] New: Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 Bug ID: 404643 Summary: Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level Product: kwin Version: 5.15.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: igor...@meta.ua Target Milestone: --- SUMMARY *Important*: the issue happens much more often if the already running instance of the application is *not* hidden to tray or minimized, when it is visible but behind one or more other windows. This issue is application-dependent. When a second instance of a single-instance application is launched (from Konsole, Application Launcher or KRunner), the corresponding primary instance gets focus with inconsistent-across-applications focus stealing settings. I tested only different focus stealing prevention levels, have set all other Window Management settings to Defaults. The following table lists applications and focus stealing prevention levels that give them focus (based on my testing in Plasma 5.14.5 and 5.15.0): Level Applications (systemsettings5, KDevelop and KInfocenter) ) I suppose applications that get focus at any level use KWindowSystem::forceActiveWindow() as described here: https://api.kde.org/frameworks/kdbusaddons/html/classKDBusService.html#af0ad38f597aedaf22a30045d0423ed0e Those few apps that get focus at levels lower than _High_ probably use custom workarounds. For example, GoldenDict uses X11 API to emulate a left mouse button click in the top-left corner of its main window to get focus. The apps that get focus only at the _None_ level use regular high-level APIs such as the following Qt-based application code: qApp->setActiveWindow( this ); raise(); activateWindow(); SOFTWARE/OS VERSIONS Linux: Manjaro 64-bit KDE Plasma Versions: 5.15.0, 5.14.5 KDE Frameworks Versions: 5.55.0, 5.54.0 Qt Versions: 5.12.1, 5.12.0 ADDITIONAL INFORMATION >From KDE documentation (https://docs.kde.org/trunk5/en/kde-workspace/kcontrol/windowbehaviour/index.html): Focus stealing prevention level -> Low: Prevention is enabled; when some window does not have support for the underlying mechanism and KWin cannot reliably decide whether to activate the window or not, it will be activated. This setting may have both worse and better results than the medium level, depending on the applications. What "underlying mechanism" do the docs refer to? KDE frameworks APIs, KWindowSystem? If most non-KDE applications do not have support for "the underlying mechanism", then I think that the current KWin behavior does not match this documentation. This issue came up as I tried to remove the low-level X11 mouse-click-emulation workaround from GoldenDict. Without the ugly workaround GoldenDict doesn't get focus when a second instance is launched on Plasma desktop. See my thoughts about possible alternative ways to get focus from the second instance here: https://github.com/goldendict/goldendict/issues/781#issuecomment-462841795. How should non-KDE, pure-Qt, single-instance applications request focus on second instance launch to get it in all Plasma versions? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #2 from Igor Kushnir --- Do you mean that each non-KDE single-instance application should contain a duplicate KWindowSystemPrivateX11::forceActiveWindow() implementation (https://code.woboq.org/qt5/kf5/kwindowsystem/src/platforms/xcb/kwindowsystem.cpp.html#_ZN23KWindowSystemPrivateX1117forceActiveWindowEyl) and possibly KStartupInfo::setNewStartupId() implementation (https://api.kde.org/frameworks/kwindowsystem/html/kstartupinfo_8cpp_source.html#l00778) in order to get focus with default Plasma Window Management settings? Are you sure that there is no bug in KWin? Shouldn't KWin activate windows without "support for the underlying mechanism" at Low focus stealing prevention level as the option's documentation states? Note that currently a very low percentage of non-KDE windows (15% of those I've tested) gets focus if the already running instance is visible. And at least some of those ~15% get focus due to hackish workarounds rather than the according standard implementation. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 404643] Launching a second instance of single-instance application doesn't give focus to the running instance at Low or higher focus stealing prevention level
https://bugs.kde.org/show_bug.cgi?id=404643 --- Comment #6 from Igor Kushnir --- > I recommend using existing libraries like KRun in combination with > KWindowsystem to achieve this. Way better solution than trying to reinvent > the wheel. KRun is part of KIO - a tier 3 framework with complex dependencies. Few non-KDE applications would want to depend on it. Reinventing the wheel also doesn't belong to application code. No wonder that so few independent apps support the startup notification standard. This standard has to be implemented in widely used cross-platform frameworks, such as Qt, in order to increase adoption. Or at least in cross-platform, lightweight, easy-to-use libraries, such as QtSingleApplication. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 407388] New: qmake fails due to a bug in qtbase-opensource-src packaging
https://bugs.kde.org/show_bug.cgi?id=407388
Bug ID: 407388
Summary: qmake fails due to a bug in qtbase-opensource-src
packaging
Product: neon
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Packages User Edition
Assignee: neon-b...@kde.org
Reporter: igor...@meta.ua
CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org
Target Milestone: ---
SUMMARY
The bug was reported 3 months ago:
https://forum.qt.io/topic/99507/project-error-library-libatomic-is-not-defined
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921930
It was fixed in Debian almost immediately as can be seen here ("Revert part of
the mkspecs movements between packages"):
https://metadata.ftp-master.debian.org/changelogs//main/q/qtbase-opensource-src/qtbase-opensource-src_5.11.3+dfsg1-1_changelog
But I can still reproduce the bug in a fully updated KDE neon system.
STEPS TO REPRODUCE
Run qmake on some pro file without the qtbase5-private-dev package installed.
OBSERVED RESULT
qmake fails with the following error: "Project ERROR: Library 'libatomic' is
not defined."
EXPECTED RESULT
qmake succeeds.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE neon 5.15 User Edition with latest updates inside a
virtual machine
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.0
--
You are receiving this mail because:
You are watching all bug changes.
[neon] [Bug 407388] qmake fails due to a bug in qtbase-opensource-src packaging
https://bugs.kde.org/show_bug.cgi?id=407388 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 407388] qmake fails due to a bug in qtbase-opensource-src packaging
https://bugs.kde.org/show_bug.cgi?id=407388 Igor Kushnir changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #1 from Igor Kushnir --- The issue is no longer present in the current version of KDE neon. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 416355] Missing "Bookmark Toolview"
https://bugs.kde.org/show_bug.cgi?id=416355 --- Comment #3 from Igor Kushnir --- Created attachment 127131 --> https://bugs.kde.org/attachment.cgi?id=127131=edit Bookmarks tool view present in kdevelop 5.5.0-1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 416355] Missing "Bookmark Toolview"
https://bugs.kde.org/show_bug.cgi?id=416355 --- Comment #4 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #2) > I suppose you built KDevelop from source and this maybe is enabled by > default. I have binary package coming from Arch Linux distribution and > cannot find it. Strange. I'm using the Arch package as well (Version: 5.5.0-1, Build Date: Sunday, February 2, 2020 10:46:37 PM EET) and the Bookmarks tool view can be enabled. Attached the tool view context menu screenshot. The Bookmarks tool view is also present in a build from git master. But even if for some reason your KDevelop doesn't have it, you are not missing much. All the buttons on my Bookmarks tool view are permanently disabled and it is completely nonfunctional. It will have to be fixed eventually. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 361760] Find/Replace in Files : Failed: no files found matching the wildcard patterns
https://bugs.kde.org/show_bug.cgi?id=361760 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #2 from Igor Kushnir --- The issue is in the Exclude pattern. It contains "/build/" pattern by default to exclude the default-named directory KDevelop creates. And each Exclude pattern is matched against a complete file path. I think it should be matched against the remainder of the path after the top-level search directory. Note that right now the Exclude functionality is broken as described in Bug 417628. I'm working on a fix to that bug. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 361760] Find/Replace in Files : Failed: no files found matching the wildcard patterns
https://bugs.kde.org/show_bug.cgi?id=361760 Igor Kushnir changed: What|Removed |Added CC||poldi...@web.de --- Comment #3 from Igor Kushnir --- *** Bug 373456 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 373456] Strange behaviour, if "find/replace" directory is named "build"
https://bugs.kde.org/show_bug.cgi?id=373456 Igor Kushnir changed: What|Removed |Added Status|REPORTED|RESOLVED CC||igor...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Igor Kushnir --- *** This bug has been marked as a duplicate of bug 361760 *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 365437] Rename local variable using "Rename" assistant breaks code
https://bugs.kde.org/show_bug.cgi?id=365437 --- Comment #11 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #10) > I look forward to your fix. I'm grateful that you interested this and are > going to fix it. Broken code was really annoying thing what I met after > refactoring. If you are curious, take a look at my merge request https://invent.kde.org/kde/kdevelop/-/merge_requests/118 that fixes this bug but fails to generally fix the broader issue. I hope someone suggests an idea how to fix the entire bug, because I don't see how that can be done. There is also my branch that fixes the other bug I described (setAddBracketsMode in 1TBS). It is referenced as a dependent branch in https://invent.kde.org/kde/kdevelop/-/merge_requests/116. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 416355] Missing "Bookmark Toolview"
https://bugs.kde.org/show_bug.cgi?id=416355 Igor Kushnir changed: What|Removed |Added CC||igor...@meta.ua --- Comment #1 from Igor Kushnir --- There is a bookmark toolview in KDevelop, but it doesn't seem to be working. To enable it, right-click on a bottom or left toolview dock and select the Bookmarks context menu item. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 409222] kdev_format_source returns "error: no commands applicable to" for any pattern
https://bugs.kde.org/show_bug.cgi?id=409222 Igor Kushnir changed: What|Removed |Added Version Fixed In||5.5.1 Latest Commit||https://invent.kde.org/kde/ ||kdevelop/commit/f56cdda54b7 ||f88b119f2c7cfb2f534b4fe7447 ||8f Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Igor Kushnir --- Git commit f56cdda54b7f88b119f2c7cfb2f534b4fe74478f by Igor Kushnir. Committed on 02/05/2020 at 16:28. Pushed by igorkushnir into branch '5.5'. Work around QDir::match() behavior change in Qt 5.12.0 QDir::match() migrated to QRegularExpression in Qt 5.12.0. In the new implementation asterisk in a wildcard no longer matches path separators. This caused two bugs in KDevelop: 1. kdev_format_source rejects input files if the 'format_sources' file is not located in the same directory as the target file. 2. Exclude filter in Find/Replace in Files has no effect (unless the user specifies almost complete paths in the format supported by Bash Filename Expansion with the globstar shell option disabled). Note that Files (aka `include`) filter in Find/Replace in Files is unaffected by the behavior change because in its code a filename rather than a path is passed as the second argument to QDir::match(). WildcardHelpers can migrate to QRegularExpression::wildcardToRegularExpression() once we require Qt 5.12.1 or later. This function was added in Qt 5.12.0 and started anchoring wildcard pattern in Qt 5.12.1. Ideally support for globstar (**) in glob patterns should be added to QRegularExpression::wildcardToRegularExpression() and to QDir::match(). In that case WildcardHelpers could be eliminated and QDir::match() could be used again. If globstar support is not added to QRegularExpression::wildcardToRegularExpression(), WildcardHelpers can port away from QRegExp, for example, by replacing `starEscape` (see the definition of wildcardToRegularExpression()) with ".*" in the value returned by wildcardToRegularExpression() and passing DotMatchesEverythingOption to QRegularExpression constructor. When we port away from QRegExp, we can change the syntax of format_sources and possibly Exclude filter to match Bash globstar syntax or perhaps some other new Qt wildcard syntax. Alternatively, we can process user-provided wildcard patterns before and/or after passing them to wildcardToRegularExpression() so as to preserve our syntax. Related: bug 417628 FIXED-IN: 5.5.1 M +1-0kdevplatform/util/CMakeLists.txt M +3-1kdevplatform/util/kdevformatfile.cpp A +59 -0kdevplatform/util/wildcardhelpers.h [License: LGPL (v2+)] M +2-1plugins/grepview/grepdialog.cpp M +4-2plugins/grepview/grepfindthread.cpp https://invent.kde.org/kde/kdevelop/commit/f56cdda54b7f88b119f2c7cfb2f534b4fe74478f -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 417628] Exclude filter in find/replace files dialog doesn't seem to work
https://bugs.kde.org/show_bug.cgi?id=417628 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Version Fixed In||5.5.1 Latest Commit||https://invent.kde.org/kde/ ||kdevelop/commit/f56cdda54b7 ||f88b119f2c7cfb2f534b4fe7447 ||8f --- Comment #2 from Igor Kushnir --- Git commit f56cdda54b7f88b119f2c7cfb2f534b4fe74478f by Igor Kushnir. Committed on 02/05/2020 at 16:28. Pushed by igorkushnir into branch '5.5'. Work around QDir::match() behavior change in Qt 5.12.0 QDir::match() migrated to QRegularExpression in Qt 5.12.0. In the new implementation asterisk in a wildcard no longer matches path separators. This caused two bugs in KDevelop: 1. kdev_format_source rejects input files if the 'format_sources' file is not located in the same directory as the target file. 2. Exclude filter in Find/Replace in Files has no effect (unless the user specifies almost complete paths in the format supported by Bash Filename Expansion with the globstar shell option disabled). Note that Files (aka `include`) filter in Find/Replace in Files is unaffected by the behavior change because in its code a filename rather than a path is passed as the second argument to QDir::match(). WildcardHelpers can migrate to QRegularExpression::wildcardToRegularExpression() once we require Qt 5.12.1 or later. This function was added in Qt 5.12.0 and started anchoring wildcard pattern in Qt 5.12.1. Ideally support for globstar (**) in glob patterns should be added to QRegularExpression::wildcardToRegularExpression() and to QDir::match(). In that case WildcardHelpers could be eliminated and QDir::match() could be used again. If globstar support is not added to QRegularExpression::wildcardToRegularExpression(), WildcardHelpers can port away from QRegExp, for example, by replacing `starEscape` (see the definition of wildcardToRegularExpression()) with ".*" in the value returned by wildcardToRegularExpression() and passing DotMatchesEverythingOption to QRegularExpression constructor. When we port away from QRegExp, we can change the syntax of format_sources and possibly Exclude filter to match Bash globstar syntax or perhaps some other new Qt wildcard syntax. Alternatively, we can process user-provided wildcard patterns before and/or after passing them to wildcardToRegularExpression() so as to preserve our syntax. Related: bug 409222 FIXED-IN: 5.5.1 M +1-0kdevplatform/util/CMakeLists.txt M +3-1kdevplatform/util/kdevformatfile.cpp A +59 -0kdevplatform/util/wildcardhelpers.h [License: LGPL (v2+)] M +2-1plugins/grepview/grepdialog.cpp M +4-2plugins/grepview/grepfindthread.cpp https://invent.kde.org/kde/kdevelop/commit/f56cdda54b7f88b119f2c7cfb2f534b4fe74478f -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 365437] Rename local variable using "Rename" assistant breaks code
https://bugs.kde.org/show_bug.cgi?id=365437 --- Comment #7 from Igor Kushnir --- I see that my braces bug is the same as Piotr's. It is triggered by a brace inserted by a formatter just before the renamed variable. The bug is in extractFormattedTextFromContext(): endOfLeftContext = matchPrefixIgnoringWhitespace(formattedMergedText, leftContext, fuzzyCharacters); The inserted brace ends up after endOfLeftContext and sneaks into code along with the renamed variable. The bug does not depend on the source formatter - happens with all of them. I'll try to fix this bug by skipping the brace and associated extra line break, etc. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 365437] Rename local variable using "Rename" assistant breaks code
https://bugs.kde.org/show_bug.cgi?id=365437
Igor Kushnir changed:
What|Removed |Added
CC||igor...@meta.ua
--- Comment #6 from Igor Kushnir ---
I have experienced similar Rename bugs in KDevelop 5.5.0:
1) it always inserted spaces between the renamed variable and parentheses;
2) sometimes it inserted out-of-place braces.
After some debugging I determined that Source Formatter kicks in during the
Rename variable refactoring in DocumentChangeSetPrivate::generateNewText():
if (formatter && (formatPolicy == DocumentChangeSet::AutoFormatChanges
|| formatPolicy ==
DocumentChangeSet::AutoFormatChangesKeepIndentation)) {
... }
GrepOutputModel sets formatPolicy to DocumentChangeSet::NoAutoFormat, so
Find/Replace in Files does not cause such bugs. Neither does simple
KTextEditor's Replace within a file.
It turned out that my Source Formatter for the C++ Language was set to the
default Artistic Style->1TBS. After switching to Artistic Style->Qt, at least
the easily reproducible space insertion issue is gone. Not sure about the
spurious braces yet.
Piotr, have you tried reproducing this bug and Bug 317299 with different C++
Source Formatters configured in KDevelop settings?
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 Igor Kushnir changed: What|Removed |Added CC||igor...@meta.ua --- Comment #4 from Igor Kushnir --- I can reproduce this bug with some formatter styles, but don't think it's easy to fix. KDevelop intentionally applies selected style reformatting when the user refactors the code, e.g. renames a variable. The relevant KDevelop code actually has a very poor performance: it reformats the whole file for each use of the variable being renamed just to "fix according to the selected style" the whitespaces around the variable names it changes. I hope this code will be thrown out in favor of a better clang-format implementation in the future. As a workaround just pick a style where the spaces don't get inserted in your code. The Qt Artistic Style works for me. -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 358798] Source formatter every time selects language as "C"
https://bugs.kde.org/show_bug.cgi?id=358798
Igor Kushnir changed:
What|Removed |Added
CC||igor...@meta.ua
--- Comment #4 from Igor Kushnir ---
Piotr, I think you are misunderstanding the configuration page. By picking a
formatter for each language in the Language combobox you can use different
formatters for different languages. The Language combobox does not show the
currently configured language, but lets you pick the language you want to
select a formatter for.
Here is what I have in my
~/.local/share/kdevelop/sessions/{session-id}/sessionrc:
[SourceFormatter]
ModelinesEnabled=false
OverrideKateIndentation=false
text/x-c++hdr=kdevastyle||Qt
text/x-c++src=kdevastyle||Qt
text/x-chdr=kdevastyle||KDELibs
text/x-csharp=kdevastyle||1TBS
text/x-csrc=kdevastyle||KDELibs
text/x-java=kdevastyle||1TBS
text/x-objcsrc=kdevastyle||1TBS
This is after I picked Qt as the style for the C++ Language and KDELibs as the
style for the C Language, while leaving the default 1TBS style for other
languages that I don't use.
So if you only use C++, configure the source formatter for this language in
KDevelop settings. However note Bug 335549: if your headers have the *.h
extension, configure the formatter for the C language as well. You could even
use different formatters for headers and source files in this case.
As for your project configuration idea, it's already implemented. There is a
Source Formatter section on the Configure Project page.
To summarize:
- custom formatting styles that a user creates are stored in
~/.config/kdeveloprc. So a user can create a custom style "My style" once, then
select it for any other session or project.
- Source formatters ("Artistic Style" or "Custom Script Formatter") and
styles (1TBS, ANSI, ... or "Gnu Indent : GNU", "Clang Format", ...) selections
for each language on the Source Formatter page of the Configure KDevelop window
are stored separately for each session (as I showed above).
- Source formatters can also be configured on a per-project basis.
In conclusion, I think there is no bug here, so this issue can be closed as not
a bug.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 365437] Rename local variable using "Rename" assistant breaks code
https://bugs.kde.org/show_bug.cgi?id=365437 --- Comment #9 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #8) > Could you tell me where you found another code formaters for KDevelop? I > have only these provided in kdevelop package? There are 12 Style options if you select "Artistic Style" in the Formatter combobox. > There couple bugs which I reported about this. Check > following: #358798, #358801, also 4 years ago. Shortly. Applying Formatter > doesn't effect, at least in configuration window. Whatever I select in > configuration, when I back then always is the same, so: "C" and "Gnu Indent: > Kernighan & Ritchie". I just replied under Bug 358798 and Bug 317299. > I will test more "Update declaration" and "Rename", maybe part of the fault > lies with Source Formater as you said. No need to test this for now. I've tested and debugged Artistic Style formatters myself and identified a few bugs that I'm going to fix. One is *this* very bug, which turned out to only be consistently reproducible with the 1TBS Artistic Style. Another bug that I'm going to fix made me think that *this* bug does not depend on the selected source formatter: selecting the 1TBS Artistic Style irreversibly sets the setAddBracketsMode Artistic Style option to true, so *this* bug becomes reproducible with any Artistic Style until KDevelop is restarted. I can't reproduce *this* bug with any of the Custom Script Formatters. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 417628] Exclude filter in find/replace files dialog doesn't seem to work
https://bugs.kde.org/show_bug.cgi?id=417628 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|ASSIGNED CC||igor...@meta.ua Assignee|kdevelop-bugs-n...@kde.org |igor...@meta.ua --- Comment #1 from Igor Kushnir --- This is one of the consequences of QDir::match() behavior change since Qt 5.12: https://bugreports.qt.io/browse/QTBUG-73797. I'm working on a fix. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 409222] kdev_format_source returns "error: no commands applicable to" for any pattern
https://bugs.kde.org/show_bug.cgi?id=409222 Igor Kushnir changed: What|Removed |Added CC||igor...@meta.ua Assignee|kdevelop-bugs-n...@kde.org |igor...@meta.ua Ever confirmed|0 |1 Status|REPORTED|ASSIGNED --- Comment #3 from Igor Kushnir --- This is one of the consequences of QDir::match() behavior change since Qt 5.12: https://bugreports.qt.io/browse/QTBUG-73797. I'm working on a fix. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 Igor Kushnir changed: What|Removed |Added CC||andreas_norda...@hotmail.co ||m --- Comment #16 from Igor Kushnir --- *** Bug 421120 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421120] Kdevelop crashed while typing if statement in C++
https://bugs.kde.org/show_bug.cgi?id=421120 Igor Kushnir changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #4 from Igor Kushnir --- *** This bug has been marked as a duplicate of bug 415872 *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421120] Kdevelop crashed while typing if statement in C++
https://bugs.kde.org/show_bug.cgi?id=421120 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #2 from Igor Kushnir --- I experience similar crashes in KDevelop 5.5.0 (Arch package) occasionally. Almost always the top of the stack is: [KCrash Handler] #6 0x7f6679241522 in QV4::MemoryManager::collectFromJSStack(QV4::MarkStack*) const () at /usr/lib/libQt5Qml.so.5 #7 0x7f66792415ae in QV4::MemoryManager::collectRoots(QV4::MarkStack*) () at /usr/lib/libQt5Qml.so.5 But today I got a slightly different stack top: [KCrash Handler] #6 0x7f98b8d3721c in () at /usr/lib/libQt5Qml.so.5 #7 0x7f98b8dbfb0a in QV4::PersistentValueStorage::mark(QV4::MarkStack*) () at /usr/lib/libQt5Qml.so.5 #8 0x7f98b8d375be in QV4::MemoryManager::collectRoots(QV4::MarkStack*) () at /usr/lib/libQt5Qml.so.5 There are several similar Kate crashes reported: Bug 419714, Bug 419579, Bug 418352, Bug 416384. In a comment to Bug 415872 Christoph Cullmann wrote "This crash in QV4 engine is prominent in all tools using it :/", so perhaps this bug should be marked as yet another duplicate of the kwin bug. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421621] Setting CMAKE_INSTALL_PREFIX is not honoured when cmake is run
https://bugs.kde.org/show_bug.cgi?id=421621 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #3 from Igor Kushnir --- There is the Show Advanced button under the CMake Cache Values view. Clicking this button shows/hides additional CMake settings. One of these settings is "Installation prefix", which probably overrides your manually configured CMAKE_INSTALL_PREFIX cache value. Adjusting the path in this field should take effect. I don't know if KDevelop's disregarding of CMAKE_INSTALL_PREFIX change in CMake Cache Values is a bug or an intentional feature (not particularly obvious or intuitive). Anyway, perhaps these settings shouldn't be labeled as "advanced" and should be visible by default... -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425986] New: Crash in BreakpointModel::save() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425986 Bug ID: 425986 Summary: Crash in BreakpointModel::save() when exiting KDevelop while debugging a program Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: CPP Debugger Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com CC: niko.s...@gmail.com Target Milestone: --- SUMMARY When a user exits KDevelop while debugging a program, a queued call to BreakpointModel::save() may be invoked during Core::cleanup() or perhaps even ~CorePrivate(). If this happens between SessionController::cleanup() (after which ICore::activeSession() starts returning nullptr) and ~DebugController() (which is the parent of BreakpointModel), the result is a crash. SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE (Debug) Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 KDevelop::BreakpointModel::save() (this=0x564f7ca2ba50) at ../kdevplatform/debugger/breakpoint/breakpointmodel.cpp:577 #5 0x7f2cb0feb312 in QtPrivate::FunctorCall, QtPrivate::List<>, void, void (KDevelop::BreakpointModel::*)()>::call(void (KDevelop::BreakpointModel::*)(), KDevelop::BreakpointModel*, void**) (f=(void (KDevelop::BreakpointModel::*)(KDevelop::BreakpointModel * const)) 0x7f2cb0fe81c2 , o=0x564f7ca2ba50, arg=0x564f89f690a8) at /usr/include/qt/QtCore/qobjectdefs_impl.h:152 #6 0x7f2cb0feaed6 in QtPrivate::FunctionPointer::call, void>(void (KDevelop::BreakpointModel::*)(), KDevelop::BreakpointModel*, void**) (f=(void (KDevelop::BreakpointModel::*)(KDevelop::BreakpointModel * const)) 0x7f2cb0fe81c2 , o=0x564f7ca2ba50, arg=0x564f89f690a8) at /usr/include/qt/QtCore/qobjectdefs_impl.h:185 #7 0x7f2cb0fea918 in QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x564f84c06f90, r=0x564f7ca2ba50, a=0x564f89f690a8, ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:418 #8 0x7f2cb18191d2 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5 #9 0x7f2cb2670702 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #10 0x7f2cb17ec7ba in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #11 0x7f2cb17ef2a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt5Core.so.5 #12 0x7f2cb1845cf4 in () at /usr/lib/libQt5Core.so.5 #13 0x7f2caf6d443c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #14 0x7f2caf7221d9 in () at /usr/lib/libglib-2.0.so.0 #15 0x7f2caf6d3221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #16 0x7f2cb1845331 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #17 0x7f2cb17eb13c in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #18 0x7f2cb17f35c4 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #19 0x564f7b86281f in main(int, char**) (argc=3, argv=0x7fff07732518) at ../app/main.cpp:850 [Inferior 1 (process 49588) detached] -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425985] New: Crash in ~DebugSession() when exiting KDevelop during or shortly after debugging a program
https://bugs.kde.org/show_bug.cgi?id=425985 Bug ID: 425985 Summary: Crash in ~DebugSession() when exiting KDevelop during or shortly after debugging a program Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: CPP Debugger Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com CC: niko.s...@gmail.com Target Milestone: --- SUMMARY When a user exits KDevelop during or shortly after debugging a program, a DebugSession object may outlive MIDebuggerPlugin. This can cause a crash in ~DebugSession(). SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE (RelWithDebInfo) Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 0x7f0ec006c66e in KDevMI::GDB::DebugSession::~DebugSession() (this=0x7f0f10003200, __in_chrg=) at /usr/src/debug/kdevelop/plugins/gdb/debugsession.cpp:72 #5 KDevMI::GDB::DebugSession::~DebugSession() (this=0x7f0f10003200, __in_chrg=) at /usr/src/debug/kdevelop/plugins/gdb/debugsession.cpp:73 #6 0x7f0f27fa5f90 in QObject::event(QEvent*) (this=0x7f0f10003200, e=0x559cab2d1860) at kernel/qobject.cpp:1301 #7 0x7f0f28c18702 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=, receiver=0x7f0f10003200, e=0x559cab2d1860) at kernel/qapplication.cpp:3671 #8 0x7f0f27f797ba in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x7f0f10003200, event=0x559cab2d1860) at ../../include/QtCore/5.15.0/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:325 #9 0x7f0f27f7c2a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=0x0, event_type=0, data=0x559c86efc150) at kernel/qcoreapplication.cpp:1815 #10 0x7f0f27fd2cf4 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x559c86f6ab90) at kernel/qeventdispatcher_glib.cpp:277 #11 0x7f0f22bd043c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #12 0x7f0f22c1e1d9 in () at /usr/lib/libglib-2.0.so.0 #13 0x7f0f22bcf221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #14 0x7f0f27fd2331 in QEventDispatcherGlib::processEvents(QFlags) (this=0x559c86f0d9f0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #15 0x7f0f27f7813c in QEventLoop::exec(QFlags) (this=this@entry=0x7ffc4a6179a0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:141 #16 0x7f0f27f805c4 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #17 0x559c850ac3b1 in main(int, char**) (argc=, argv=0x7ffc4a617b08) at /usr/src/debug/kdevelop/app/main.cpp:850 [Inferior 1 (process 652375) detached] -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 Igor Kushnir changed: What|Removed |Added Component|Language Support: CPP (old) |general --- Comment #8 from Igor Kushnir --- (In reply to Jaka Kranjc from comment #7) > Hasn't the old language model been replaced already? > > Anyway, in my case I have indentation set to tabs only and KDevelop > correctly fixes it for eg. pasted code or when cleaning something with mixed > indentation. So it's not at all clear why it thinks it's suddenly ok to use > normal spaces. > In these cases there should be none, not even tabs. The bug is actually in formatting code somewhere, not in language support. I don't know where it is exactly, so I'm changing this bug's Component to "general". If I recall correctly, when I selected Qt Artistic Style and adjusted it to use tabs, this space-inserting issue disappeared. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 377639] Crash in "'CTest' is already being executed" dialog.
https://bugs.kde.org/show_bug.cgi?id=377639 --- Comment #8 from Igor Kushnir --- (In reply to Christoph Roick from comment #7) > How exactly do you reproduce the behavior? I created a session with the > three projects you mention and selected "Run All Tests", but there is no > dialog showing up about a cmake job. I have noticed that the tests do not appear right after opening projects. You have to wait for the projects to be parsed and their tests to appear in Unit Tests tool view. The dialog appears more reliably (even with just two open projects, e.g. kio and ktexteditor) in KDevelop built in Debug mode, though I have no problem triggering it in Release either. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 426535] Indentation when applying renaming solution
https://bugs.kde.org/show_bug.cgi?id=426535 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Igor Kushnir --- *** This bug has been marked as a duplicate of bug 317299 *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 Igor Kushnir changed: What|Removed |Added CC||s...@lynxlynx.info --- Comment #6 from Igor Kushnir --- *** Bug 426535 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 377639] Crash in "'CTest' is already being executed" dialog.
https://bugs.kde.org/show_bug.cgi?id=377639
Igor Kushnir changed:
What|Removed |Added
CC||igor...@gmail.com
--- Comment #5 from Igor Kushnir ---
This crash still happens in KDevelop 5.6. Because of
https://commits.kde.org/kdevelop/d896e7489b743d8691e480378c86f2b1ee0524b0 the
message and the button texts are different now. For example, when I open 3
projects - drkonqi, kdevelop, kio - and Run All Tests, I get one or more {"Job
Already Running", "'cmake' is already being executed."} dialogs with three
buttons: "Cancel", "Kill All Instances", "Start Another". Only "Start Another"
is safe (and obviously the correct choice). The other two choices usually end
in a crash (either immediate or after I stop the stuck test jobs).
I think that the proper fix is to not show this dialog in such situations.
Either mark the jobs as "internal" and always silently "start another", or
assign unique names to these jobs so that NativeAppJob doesn't consider them
equal.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 372795] KDevelop crashes after running unit tests when CTest is already running
https://bugs.kde.org/show_bug.cgi?id=372795 Igor Kushnir changed: What|Removed |Added Status|REPORTED|RESOLVED CC||igor...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Igor Kushnir --- *** This bug has been marked as a duplicate of bug 377639 *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 377639] Crash in "'CTest' is already being executed" dialog.
https://bugs.kde.org/show_bug.cgi?id=377639 Igor Kushnir changed: What|Removed |Added CC||k...@jbev.net --- Comment #6 from Igor Kushnir --- *** Bug 372795 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 426070] Deadlock in ~QQmlEngine() inside ~WelcomePageWidget() when exiting KDevelop right after starting it - before Welcome Page is loaded
https://bugs.kde.org/show_bug.cgi?id=426070 --- Comment #1 from Igor Kushnir --- > I have reproduced it in Debug and Release KDevelop builds; with several small > projects open, with an empty session and with a new empty session. Actually I probably made a mistake in this statement: the deadlock can be easily reproduced only with a (possibly new) empty session. I cannot reproduce it in a session with open projects. Not only projects, even files open in a session can make the deadlock more difficult to reproduce. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 426070] New: Deadlock in ~QQmlEngine() inside ~WelcomePageWidget() when exiting KDevelop right after starting it - before Welcome Page is loaded
https://bugs.kde.org/show_bug.cgi?id=426070 Bug ID: 426070 Summary: Deadlock in ~QQmlEngine() inside ~WelcomePageWidget() when exiting KDevelop right after starting it - before Welcome Page is loaded Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- SUMMARY This deadlock is extremely easy to reproduce: start KDevelop and exit it as soon as possible => KDevelop fails to exit, i.e. the process remains running. I have reproduced it in Debug and Release KDevelop builds; with several small projects open, with an empty session and with a new empty session. For example, launch KDevelop with the following command: `kdevelop -n tmp` (or `kdevelop -s tmp` if the "tmp" session already exists). SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION This deadlock is clearly an upstream issue: QTBUG-75777. When I apply the patch that fixes it (https://codereview.qt-project.org/c/qt/qtdeclarative/+/263540), the deadlock doesn't happen. When I run the following command while KDevelop process is deadlocked (replace "123456" with the kdevelop process ID): gdb -batch -ex "thread apply all bt" -ex "quit" -p 123456 > kdevelop-deadlock.bt I always get a backtrace very similar to the one pasted below. When I run the same gdb command a few seconds, minutes or even an hour later for the same deadlocked process, I get exactly the same backtrace. BACKTRACE (with debugging symbols for KDevelop, qtbase and qtdeclarative) [New LWP 463276] [New LWP 463277] [New LWP 463278] [New LWP 463279] [New LWP 463280] [New LWP 463281] [New LWP 463282] [New LWP 463283] [New LWP 463284] [New LWP 463285] [New LWP 463286] [New LWP 463287] [New LWP 463293] [New LWP 463294] [New LWP 463295] [New LWP 463296] [New LWP 463297] [New LWP 463298] [New LWP 463299] [New LWP 463300] [New LWP 463302] [New LWP 463306] [New LWP 463308] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 0x7f60e47066a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 Thread 24 (Thread 0x7f6074bd3640 (LWP 463308)): #0 0x7f60e51ca46f in poll () at /usr/lib/libc.so.6 #1 0x7f60e1c94168 in () at /usr/lib/libglib-2.0.so.0 #2 0x7f60e1c45221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x7f60e58eb331 in QEventDispatcherGlib::processEvents(QFlags) (this=0x7f605c000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #4 0x7f60e589113c in QEventLoop::exec(QFlags) (this=this@entry=0x7f6074bd2880, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:141 #5 0x7f60e56acc32 in QThread::exec() (this=) at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #6 0x7f60e56ade0f in QThreadPrivate::start(void*) (arg=0x7f60e82b28e8 ) at thread/qthread_unix.cpp:342 #7 0x7f60e47003e9 in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f60e51d5293 in clone () at /usr/lib/libc.so.6 Thread 23 (Thread 0x7f60755fa640 (LWP 463306)): #0 0x7f60e51ca46f in poll () at /usr/lib/libc.so.6 #1 0x7f60e1c94168 in () at /usr/lib/libglib-2.0.so.0 #2 0x7f60e1c45221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x7f60e58eb331 in QEventDispatcherGlib::processEvents(QFlags) (this=0x7f6068000b60, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #4 0x7f60e589113c in QEventLoop::exec(QFlags) (this=this@entry=0x7f60755f9880, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:141 #5 0x7f60e56acc32 in QThread::exec() (this=) at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #6 0x7f60e56ade0f in QThreadPrivate::start(void*) (arg=0x55db3c9960f0) at thread/qthread_unix.cpp:342 #7 0x7f60e47003e9 in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f60e51d5293 in clone () at /usr/lib/libc.so.6 Thread 22 (Thread 0x7f60777fe640 (LWP 463302)): #0 0x7f60e47066a2 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f60e56b3e84 in QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x55db3c87ff00) at thread/qwaitcondition_unix.cpp:146 #2 QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=this@entry=0x55db3c87fe58, mutex=mutex@entry=0x55db3c87fe50, deadline=...) at thread/qwaitcondition_unix.cpp:225 #3 0x7f60e76a200b in QQmlThreadPrivate::wait() (this=0x55db3c87fde0) at /usr/include/qt/QtCore/qdeadlinetimer.h:68 #4 QQmlThread::internalCallMethodInMain(QQmlThread::Message*) (this=0x55db3c87fc80, message=) at
[kdevelop] [Bug 423651] KDevelop crashed on exit before CTest evaluation finished
https://bugs.kde.org/show_bug.cgi?id=423651 Igor Kushnir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/ae9f45 ||ae7451a33fe9fce66612140f9a1 ||3193bd6 Version Fixed In||5.6.1 --- Comment #5 from Igor Kushnir --- Git commit ae9f45ae7451a33fe9fce66612140f9a13193bd6 by Igor Kushnir. Committed on 07/10/2020 at 10:26. Pushed by igorkushnir into branch '5.6'. Early-return from CTestFindJob::updateReady() if the job is finished When a user exits KDevelop while a CTestFindJob is still working, the job is killed from RunController::cleanup() and its KJob parent calls deleteLater(). But the killed job can be still not destroyed after DUChain::shutdown() is called, which results in a crash if CTestFindJob::updateReady() is then invoked via Qt::QueuedConnection. Note that ~ParseJob() queues calls to CTestFindJob::updateReady(), which can then be invoked after DUChain::shutdown(), if ParseJob-s are running when the user exits KDevelop and no event loop is entered in the time between the ~ParseJob() and DUChain::shutdown() calls (sometimes the optional QCoreApplication::processEvents() call in BackgroundParser::waitForIdle() intervenes and prevents the crash). Core::cleanup() calls backgroundParser()->waitForIdle(), which ensures that all parse jobs finish, are destroyed and queue "updateReady" calls. FIXED-IN: 5.6.1 M +10 -0plugins/cmake/testing/ctestfindjob.cpp https://invent.kde.org/kdevelop/kdevelop/commit/ae9f45ae7451a33fe9fce66612140f9a13193bd6 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427386] Segfault in ProjectController::reparseProject()=>...=>RunController::checkState() when exiting KDevelop soon after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427386 Igor Kushnir changed: What|Removed |Added Version Fixed In||5.6.1 Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/89077c ||7c9d97ab98fe832958afb5ab24d ||0dbae44 Status|ASSIGNED|RESOLVED --- Comment #1 from Igor Kushnir --- Git commit 89077c7c9d97ab98fe832958afb5ab24d0dbae44 by Igor Kushnir. Committed on 07/10/2020 at 10:11. Pushed by igorkushnir into branch '5.6'. Don't process events in ParseProjectJob::start() >From KJob::start() documentation: Warning: Never implement any synchronous workload in this method. This method should just trigger the job startup, not do any work itself. It is expected to be non-blocking. When a user exits KDevelop in the ParseProjectJob::start()'s nested event loop, RunController may be destroyed in the time between `job->start();` and `checkState();` statements in RunController::registerJob(). The result is a segmentation fault in RunController::checkState(). FIXED-IN: 5.6.1 M +9-0kdevplatform/language/backgroundparser/parseprojectjob.cpp M +1-0kdevplatform/language/backgroundparser/parseprojectjob.h https://invent.kde.org/kdevelop/kdevelop/commit/89077c7c9d97ab98fe832958afb5ab24d0dbae44 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427387] Crash in ParseProjectJob::start() when exiting KDevelop soon after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427387 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/0b037a ||880018e5c7d679a9127b0f8 ||06aa926 Version Fixed In||5.6.1 --- Comment #1 from Igor Kushnir --- Git commit 0b037a880018e5c7d679a9127b0f806aa926 by Igor Kushnir. Committed on 07/10/2020 at 10:11. Pushed by igorkushnir into branch '5.6'. Kill ParseProjectJob before closing its project Remove the now redundant deleting of the ParseProjectJob when its project is destroyed. ParseProjectJob objects are created in ProjectController::reparseProject(), which is called when the project is already fully open. So the project is guaranteed to be closed before it is destroyed. A Project is destroyed via deleteLater() after it is closed, so if the event loop is busy at the time, ::destroyed can be emitted much later than IProjectController::projectClosing(). With this commit ParseProjectJob is killed earlier than it was destroyed without the commit. Early-return from ParseProjectJob::queueFilesToParse() not only when the job has been destroyed, but when it has been killed too. The earlier return not just avoids unnecessary work, but is essential during the application shutdown: prevents a crash by not accessing IndexedString after DUChain::shutdown(). Note that KJob::kill() calls deleteLater(), so a job can be destroyed a long time after it is killed if the event loop is busy, as it is at shutdown. ParseProjectJob is killed early in the shutdown process from RunController::cleanup() - before ProjectController::cleanup(), which would kill it otherwise, and (importantly to prevent the crash) before DUChain::shutdown(). Remove the shuttingDown() check from ParseProjectJob::start(), because this member function doesn't access globals on its own. The appropriate safety checks are now performed in the scheduled ParseProjectJob::queueFilesToParse(). Don't call deleteLater() in ParseProjectJob::doKill() just before returning true: rely on auto-delete KJob base class to call it. FIXED-IN: 5.6.1 M +24 -13 kdevplatform/language/backgroundparser/parseprojectjob.cpp M +0-3kdevplatform/language/backgroundparser/parseprojectjob.h M +3-0kdevplatform/shell/projectcontroller.cpp https://invent.kde.org/kdevelop/kdevelop/commit/0b037a880018e5c7d679a9127b0f806aa926 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 329246] Crash when project is closed before CTest evaluation finished
https://bugs.kde.org/show_bug.cgi?id=329246 Igor Kushnir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/103ab0 ||be11f659cf52d86a5c01d749b70 ||989091b Resolution|--- |FIXED Version Fixed In||5.6.1 --- Comment #6 from Igor Kushnir --- Git commit 103ab0be11f659cf52d86a5c01d749b70989091b by Igor Kushnir. Committed on 07/10/2020 at 10:26. Pushed by igorkushnir into branch '5.6'. Kill CTestFindJob when its project is destroyed When a user closes a project while its associated CTestFindJob is still working, the job is not notified and keeps running. After that, when BackgroundParser eventually parses all documents requested by the job, the job calls TestController::addTestSuite(). Inside this call the CTestSuite::project() pointer is dereferenced in TestView::addTestSuite() => TestView::itemForProject(), which causes a segmentation fault. Ideally all associated CTestFindJob-s should be killed just before or just after a project is closed to revert their no longer useful requests to BackgroundParser as soon as possible. However, reliably detecting that the project is no longer open is not straightforward, especially if the project opening is aborted or the project is closed even before a CTestFindJob is created. My implementation of such a proper fix is intertwined with several other CTest-, TestController- and TestView-related fixes. The combined fix will be so large that it won't fit into the 5.6 branch. So this commit implements a simple temporary workaround for the fairly easy to trigger crash: check if the project is destroyed in CTestFindJob::updateReady() and kill the job if this is the case. FIXED-IN: 5.6.1 M +7-0plugins/cmake/testing/ctestfindjob.cpp M +2-1plugins/cmake/testing/ctestsuite.h https://invent.kde.org/kdevelop/kdevelop/commit/103ab0be11f659cf52d86a5c01d749b70989091b -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427481] New: Quick Open plugin does not support nested project directories
https://bugs.kde.org/show_bug.cgi?id=427481 Bug ID: 427481 Summary: Quick Open plugin does not support nested project directories Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: UI: QuickOpen Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- SUMMARY Quick Open plugin assumes that a given path can belong to a single project. See struct ProjectFile in https://commits.kde.org/kdevelop?path=plugins/quickopen/projectfilequickopen.h. When a file belongs to multiple open projects, closing one of the projects removes the file from Quick Open file list. STEPS TO REPRODUCE 1. Open a project that has a subdirectory with a CMakeLists.txt file in it. 2. Check that a file in the aforementioned subdirectory can be opened via Quick Open search. 3. Open the aforementioned project's subdirectory as another project. 4. Check that the file from step 2 can still be opened via Quick Open search. 5. Close the subdirectory project. 6. Check if the file from step 4 can still be opened via Quick Open search. OBSERVED RESULT The file is no longer available in Quick Open list. EXPECTED RESULT The file is still available in Quick Open list. ADDITIONAL INFORMATION First of all: is there a use case for nested project directories? And should KDevelop support file paths that belong to multiple open projects? If this should be supported, a possible fix is to store a QVector projectPaths in the ProjectFile struct. In ProjectFileDataProvider::fileRemovedFromSet(): if the file to be removed has projectPaths.size() > 1, simply remove the project path of the ProjectFileItem from projectPaths; if projectPaths.size() == 1, remove the entire ProjectFile. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427246] New: SIGTRAP/SIGSEGV while running any version of KDevelop under GDB after a recent system update
https://bugs.kde.org/show_bug.cgi?id=427246 Bug ID: 427246 Summary: SIGTRAP/SIGSEGV while running any version of KDevelop under GDB after a recent system update Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- SUMMARY Since the yesterday's large Manjaro stable update, debugging KDevelop from KDevelop or from GDB command line results in multiple SIGTRAP and/or SIGSEGV signals. STEPS TO REPRODUCE 1. source /path/to/prefix.sh (to set QT_PLUGIN_PATH and other environment variables) 2. gdb ./bin/kdevelop 3. (gdb) start -s 'test kdevelop5 session' 4. (gdb) c OBSERVED RESULT Thread 26 received signal SIGSEGV, Segmentation fault. [Switching to LWP 44850] 0x77fd575b in dl_main () from /lib64/ld-linux-x86-64.so.2 (gdb) thread apply all bt Thread 26 (LWP 44850): #0 0x77fd575b in dl_main () from /lib64/ld-linux-x86-64.so.2 #1 0x77feb992 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2 #2 0x77fd2ff1 in _dl_start () from /lib64/ld-linux-x86-64.so.2 #3 0x77fd2098 in _start () from /lib64/ld-linux-x86-64.so.2 #4 0x0003 in ?? () #5 0x7fffe89b in ?? () #6 0x7fffe8aa in ?? () #7 0x7fffe8b1 in ?? () #8 0x in ?? () EXPECTED RESULT KDevelop runs normally without SIGTRAP or SIGSEGV signals. SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION When I debug KDevelop from KDevelop, I usually get SIGTRAP signals instead of SIGSEGV and can sometimes temporarily work them around by setting a temporary hardware breakpoint at the SIGTRAP address: *** Program received signal SIGTRAP (Trace/breakpoint trap) ***(gdb) 28thread apply all bt Thread 33 (LWP 45790): #0 0x7f8ee90c38fe in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #1 0x7f8ee4a30088 in ?? () #2 0x7ffde5e39340 in ?? () #3 0x7ffde5e39440 in ?? () #4 0x7f8ee90c3320 in ?? () from /lib64/ld-linux-x86-64.so.2 #5 0x7ffde5e39360 in ?? () #6 0x5571d3123ca0 in ?? () #7 0x7f8ee4ab7a00 in ?? () #8 0x7ffde5e39340 in ?? () #9 0x7ffde5e3924c in ?? () #10 0x80001001 in ?? () #11 0xb020296fce29d303 in ?? () #12 0xff68 in ?? () #13 0x0003 in ?? () #14 0x7f8ee50ac9a9 in ?? () #15 0xfffe in ?? () #16 0xb020296fcce9d303 in ?? () #17 0xb0c62beee84bd303 in ?? () #18 0x5571 in ?? () #19 0x5571d39d04d0 in ?? () #20 0x0003 in ?? () #21 0x7f8ee512430b in ?? () #22 0x0003 in ?? () #23 0x5571d39d04d0 in ?? () #24 0x in ?? () Thread 32 (LWP 45948): #0 0x7f8e6b72be4b in ?? () #1 0x7f8e5400c858 in ?? () #2 0x7f8e5400c890 in ?? () #3 0x7f8e5400c858 in ?? () #4 0x7f8e6b72c085 in ?? () #5 0x7f8e5400c858 in ?? () #6 0x7f8e6b72c19a in ?? () #7 0x7f8e54003e00 in ?? () #8 0x7f8e6b71e793 in ?? () #9 0x0100 in ?? () #10 0x in ?? () Thread 30 (LWP 45946): #0 0x7f8e6b67ee98 in ?? () #1 0x000a in ?? () #2 0x7f8e6b729850 in ?? () #3 0x7f8e505e1ea0 in ?? () #4 0x7f8e6b72b939 in ?? () #5 0x7f8e505e0248 in ?? () #6 0x7f8e6acd44c0 in ?? () #7 0x7f8e6acd44b8 in ?? () #8 0x in ?? () Thread 29 (LWP 45943): #0 0x7f8ee49e672b in ?? () #1 0x7f8e5c013060 in ?? () #2 0x002ad2313d00 in ?? () #3 0x7f8e5c013420 in ?? () #4 0x7f8e6b6e9e3e in ?? () #5 0x7f8e5c013110 in ?? () #6 0x7f8e5c013288 in ?? () #7 0x7f8e5c013110 in ?? () #8 0x7f8e6b6e7fdf in ?? () #9 0x in ?? () 28^done (gdb) 31f 0 #0 0x7f8ee90c38fe in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 31^done (gdb) 34thbreak *0x7f8ee90c38fe Hardware assisted breakpoint 1 at 0x7f8ee90c38fe 34^done (gdb) 37c Continuing. 37^running (gdb) 42c Continuing. 42^running After these commands KDevelop usually runs normally until a code breakpoint is hit, at which point the debugged instance receives SIGTRAP/SIGSEGV signals and eventually crashes. I tried debugging other applications - kate, audacious, flacon, drkonqi - and none of them crashes under GDB. FAILED WORKAROUNDS 1. Older kernel: the same crash happens under linux57 (5.7.19) built on 2020-09-09. 2. Different KDevelop version: the same crash happens with several of my older builds and fresh ones too. 3. KDevelop Release build: the same crash happens in my system-installed version built more than a month ago. 4. Attach to a running KDevelop instance: it appears to run OK until a code breakpoint is hit, at which point the debugged instance receives SIGTRAP/SIGSEGV signals and eventually
[kdevelop] [Bug 427227] kdevelop parser crashes with SEGFAULT
https://bugs.kde.org/show_bug.cgi?id=427227 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #6 from Igor Kushnir --- I logged *that* GDB crash as Bug 427246. Please comment under that bug if you have more information. Hopefully we can figure out why it happens... -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427379] New: Segfault in ProjectFileDataProvider::projectOpened() when disabling Quick Open plugin right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427379 Bug ID: 427379 Summary: Segfault in ProjectFileDataProvider::projectOpened() when disabling Quick Open plugin right after a large project is opened Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: UI: QuickOpen Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- SUMMARY When a user disables Quick Open plugin right after a large project is opened, before ProjectFileDataProvider::projectOpened() slot returns, the ProjectFileDataProvider object is already destroyed when the projectOpened()'s QApplication::processEvents() returns. This causes a segmentation fault when the destroyed ProjectFileDataProvider resumes adding files to set. STEPS TO REPRODUCE 1. Open a large project with tens of thousands of files, such as KDevelop itself. 2. Locate the Quick Open plugin on KDevelop's Configure=>Plugins page and uncheck its checkbox while the project is being loaded. Do not press "Apply" or "OK" button yet. 3. As soon as the just opened project appears in Projects tool view, press the "OK" button in the KDevelop's Configure dialog. SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 std::__atomic_base::load(std::memory_order) const (__m=std::memory_order_relaxed, this=0x40) at /usr/include/c++/10.2.0/bits/atomic_base.h:426 #5 QAtomicOps::loadRelaxed(std::atomic const&) (_q_value=...) at /usr/include/qt/QtCore/qatomic_cxx11.h:239 #6 0x7f44103a5a1a in QBasicAtomicInteger::loadRelaxed() const (this=0x40) at /usr/include/qt/QtCore/qbasicatomic.h:107 #7 0x7f44103af5c0 in QtPrivate::RefCount::isShared() const (this=0x40) at /usr/include/qt/QtCore/qrefcount.h:101 #8 0x7f44103cc49b in QVector::isDetached() const (this=0x55c4d27d0ab0) at /usr/include/qt/QtCore/qvector.h:113 #9 0x7f44103cb64b in QVector::detach() (this=0x55c4d27d0ab0) at /usr/include/qt/QtCore/qvector.h:405 #10 0x7f44103c9962 in QVector::end(QTypedArrayData::iterator) (this=0x55c4d27d0ab0) at /usr/include/qt/QtCore/qvector.h:223 #11 0x7f44103c6d82 in ProjectFileDataProvider::fileAddedToSet(KDevelop::ProjectFileItem*) (this=0x55c4d27d0a80, file=0x7f44381208e0) at ../plugins/quickopen/projectfilequickopen.cpp:270 #12 0x7f44103c6a69 in ProjectFileDataProvider::projectOpened(KDevelop::IProject*) (this=0x55c4d27d0a80, project=0x55c4d807eb10) at ../plugins/quickopen/projectfilequickopen.cpp:249 #13 0x7f44103d03e8 in QtPrivate::FunctorCall, QtPrivate::List, void, void (ProjectFileDataProvider::*)(KDevelop::IProject*)>::call(void (ProjectFileDataProvider::*)(KDevelop::IProject*), ProjectFileDataProvider*, void**) (f=(void (ProjectFileDataProvider::*)(ProjectFileDataProvider * const, KDevelop::IProject *)) 0x7f44103c6984 , o=0x55c4d27d0a80, arg=0x7ffe68903210) at /usr/include/qt/QtCore/qobjectdefs_impl.h:152 #14 0x7f44103ced66 in QtPrivate::FunctionPointer::call, void>(void (ProjectFileDataProvider::*)(KDevelop::IProject*), ProjectFileDataProvider*, void**) (f=(void (ProjectFileDataProvider::*)(ProjectFileDataProvider * const, KDevelop::IProject *)) 0x7f44103c6984 , o=0x55c4d27d0a80, arg=0x7ffe68903210) at /usr/include/qt/QtCore/qobjectdefs_impl.h:185 #15 0x7f44103cd69a in QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55c4d10ca8a0, r=0x55c4d27d0a80, a=0x7ffe68903210, ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:418 #16 0x7f44aa18fa26 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffe68903210, r=0x55c4d27d0a80, this=0x55c4d10ca8a0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #17 doActivate(QObject*, int, void**) (sender=0x55c4cfc1dde0, signal_index=4, argv=0x7ffe68903210) at kernel/qobject.cpp:3886 #18 0x7f44aca91550 in KDevelop::IProjectController::projectOpened(KDevelop::IProject*) (this=0x55c4cfc1dde0, _t1=0x55c4d807eb10) at kdevplatform/interfaces/KDevPlatformInterfaces_autogen/EWIEGA46WW/moc_iprojectcontroller.cpp:266 #19 0x7f44adf7e48c in KDevelop::ProjectController::projectImportingFinished(KDevelop::IProject*) (this=0x55c4cfc1dde0, project=0x55c4d807eb10) at ../kdevplatform/shell/projectcontroller.cpp:1000 #20 0x7f44adf9738d in KDevelop::ProjectPrivate::importDone(KJob*) (this=0x55c4d45570c0, job=0x55c4d7c37b70) at ../kdevplatform/shell/project.cpp:221 #21 0x7f44adf94c0a in operator()(KJob*) const (__closure=0x55c4d326e220, job=0x55c4d7c37b70) at ../kdevplatform/shell/project.cpp:548 #22 0x7f44adf96d7c in QtPrivate::FunctorCall,
[kdevelop] [Bug 427378] New: Segfault in ProjectFileDataProvider::projectOpened()'s nested event loop when exiting KDevelop right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427378 Bug ID: 427378 Summary: Segfault in ProjectFileDataProvider::projectOpened()'s nested event loop when exiting KDevelop right after a large project is opened Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: UI: QuickOpen Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- SUMMARY When a user exits KDevelop right after a large project is opened, before ProjectFileDataProvider::projectOpened() slot returns, IProjectController::projectClosing() signal is emitted before some slots connected to IProjectController::projectOpened() signal ale invoked (more precisely, the slots that were connected to projectOpened() signal later than the ProjectFileDataProvider::projectOpened() slot). Thus a valid assumption that a slot connected to projectOpened() is always called before a slot connected to projectClosing() becomes incorrect and causes a segmentation fault in ClassModel::removeProjectNode(). STEPS TO REPRODUCE 1. Open a large project with tens of thousands of files, such as KDevelop itself. 2. Exit KDevelop as soon as the just opened project appears in Projects tool view. SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE (RelWithDebInfo) Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f3bdd900580 (LWP 40040))] Thread 1 (Thread 0x7f3bdd900580 (LWP 40040)): [KCrash Handler] #6 0x7f3bf519a711 in ClassModelNodes::Node::row() (this=0x0) at ../kdevplatform/language/classmodel/classmodelnode.cpp:487 #7 0x7f3bf519a514 in ClassModelNodes::Node::removeNode(ClassModelNodes::Node*) (this=0x559e9ad20ae0, a_child=0x0) at ../kdevplatform/language/classmodel/classmodelnode.cpp:446 #8 0x7f3bf51967c0 in ClassModel::removeProjectNode(KDevelop::IProject*) (this=0x559e9ad20aa0, project=0x559e9d2c3760) at ../kdevplatform/language/classmodel/classmodel.cpp:272 #9 0x7f3bf5197fa9 in QtPrivate::FunctorCall, QtPrivate::List, void, void (ClassModel::*)(KDevelop::IProject*)>::call(void (ClassModel::*)(KDevelop::IProject*), ClassModel*, void**) (f=(void (ClassModel::*)(ClassModel * const, KDevelop::IProject *)) 0x7f3bf5196772 , o=0x559e9ad20aa0, arg=0x7ffc5526f790) at /usr/include/qt/QtCore/qobjectdefs_impl.h:152 #10 0x7f3bf5197dfd in QtPrivate::FunctionPointer::call, void>(void (ClassModel::*)(KDevelop::IProject*), ClassModel*, void**) (f=(void (ClassModel::*)(ClassModel * const, KDevelop::IProject *)) 0x7f3bf5196772 , o=0x559e9ad20aa0, arg=0x7ffc5526f790) at /usr/include/qt/QtCore/qobjectdefs_impl.h:185 #11 0x7f3bf519791a in QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x559e9ad1d730, r=0x559e9ad20aa0, a=0x7ffc5526f790, ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:414 #12 0x7f3bf21fd50e in () at /usr/lib/libQt5Core.so.5 #13 0x7f3bf4cc18da in KDevelop::IProjectController::projectClosing(KDevelop::IProject*) (this=0x559e97168110, _t1=0x559e9d2c3760) at kdevplatform/interfaces/KDevPlatformInterfaces_autogen/EWIEGA46WW/moc_iprojectcontroller.cpp:273 #14 0x7f3bf61ed683 in KDevelop::ProjectController::takeProject(KDevelop::IProject*) (this=0x559e97168110, proj=0x559e9d2c3760) at ../kdevplatform/shell/projectcontroller.cpp:1070 #15 0x7f3bf61ed759 in KDevelop::ProjectController::closeProject(KDevelop::IProject*) (this=0x559e97168110, proj=0x559e9d2c3760) at ../kdevplatform/shell/projectcontroller.cpp:1090 #16 0x7f3bf61ed81e in KDevelop::ProjectController::closeAllProjects() (this=0x559e97168110) at ../kdevplatform/shell/projectcontroller.cpp:1100 #17 0x7f3bf61ea918 in KDevelop::ProjectController::cleanup() (this=0x559e97168110) at ../kdevplatform/shell/projectcontroller.cpp:665 #18 0x7f3bf61d9c6d in KDevelop::Core::cleanup() (this=0x559e97676230) at ../kdevplatform/shell/core.cpp:395 #19 0x7f3bf61d996e in KDevelop::Core::shutdown() (this=0x559e97676230) at ../kdevplatform/shell/core.cpp:356 #20 0x7f3bf61b47e3 in KDevelop::MainWindow::~MainWindow() (this=0x559e97695730, __in_chrg=, __vtt_parm=) at ../kdevplatform/shell/mainwindow.cpp:150 #21 0x7f3bf61b48a6 in KDevelop::MainWindow::~MainWindow() (this=0x559e97695730, __in_chrg=, __vtt_parm=) at ../kdevplatform/shell/mainwindow.cpp:154 #22 0x7f3bf21f50a0 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5 #23 0x7f3bf30ac439 in QWidget::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5 #24 0x7f3bf31c6515 in QMainWindow::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5 #25
[kdevelop] [Bug 427379] Segfault in ProjectFileDataProvider::projectOpened() when disabling Quick Open plugin right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427379 Igor Kushnir changed: What|Removed |Added Status|REPORTED|ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427378] Segfault in ProjectFileDataProvider::projectOpened()'s nested event loop when exiting KDevelop right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427378 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427378] Segfault in ProjectFileDataProvider::projectOpened()'s nested event loop when exiting KDevelop right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427378 Igor Kushnir changed: What|Removed |Added Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427379] Segfault in ProjectFileDataProvider::projectOpened() when disabling Quick Open plugin right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427379 Igor Kushnir changed: What|Removed |Added Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425991] Crash in BreakpointModel::updateState() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425991 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|ASSIGNED Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425986] Crash in BreakpointModel::save() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425986 Igor Kushnir changed: What|Removed |Added Status|REPORTED|ASSIGNED Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425993] Crash in BreakpointModel::breakpoint() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425993 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Status|REPORTED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425994] Crashes caused by DebugController::showStepInSource() when a user requests KDevelop exit just before a code breakpoint is hit
https://bugs.kde.org/show_bug.cgi?id=425994 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Status|REPORTED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425985] Crash in ~DebugSession() when exiting KDevelop during or shortly after debugging a program
https://bugs.kde.org/show_bug.cgi?id=425985 Igor Kushnir changed: What|Removed |Added Status|REPORTED|ASSIGNED Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427386] New: Segfault in ProjectController::reparseProject()=>...=>RunController::checkState() when exiting KDevelop right after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427386 Bug ID: 427386 Summary: Segfault in ProjectController::reparseProject()=>...=>RunControlle r::checkState() when exiting KDevelop right after a large project is opened Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- SUMMARY When a user exits KDevelop right after a large project is opened, before ParseProjectJob::start() returns, RunController may be destroyed in the time between `job->start();` and `checkState();` statements in RunController::registerJob(). The result is a segmentation fault in RunController::checkState(). SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE (Release) Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f8b392eebc0 (LWP 120878))] Thread 1 (Thread 0x7f8b392eebc0 (LWP 120878)): [KCrash Handler] #6 0x7f8b51b43089 in KDevelop::RunController::checkState() () at /usr/lib/libKDevPlatformShell.so.55 #7 0x7f8b51b442b9 in KDevelop::RunController::registerJob(KJob*) () at /usr/lib/libKDevPlatformShell.so.55 #8 0x7f8b51b0c09a in KDevelop::ProjectController::reparseProject(KDevelop::IProject*, bool, bool) () at /usr/lib/libKDevPlatformShell.so.55 #9 0x7f8b51b0f0ab in KDevelop::ProjectController::projectImportingFinished(KDevelop::IProject*) () at /usr/lib/libKDevPlatformShell.so.55 #10 0x7f8b5029250e in () at /usr/lib/libQt5Core.so.5 #11 0x7f8b5058ce4d in KJob::result(KJob*, KJob::QPrivateSignal) () at /usr/lib/libKF5CoreAddons.so.5 #12 0x7f8b5058d93c in KJob::finishJob(bool) () at /usr/lib/libKF5CoreAddons.so.5 #13 0x7f8b51a29945 in KDevelop::ExecuteCompositeJob::slotResult(KJob*) () at /usr/lib/libKDevPlatformUtil.so.55 #14 0x7f8b5029250e in () at /usr/lib/libQt5Core.so.5 #15 0x7f8b5058ce4d in KJob::result(KJob*, KJob::QPrivateSignal) () at /usr/lib/libKF5CoreAddons.so.5 #16 0x7f8b5058d93c in KJob::finishJob(bool) () at /usr/lib/libKF5CoreAddons.so.5 #17 0x7f8b4eacb5a1 in () at /usr/lib/libKDevPlatformProject.so.55 #18 0x7f8b5028a30a in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5 #19 0x7f8b50f00362 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #20 0x7f8b50f09819 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #21 0x7f8b5025ca12 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #22 0x7f8b5025f276 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt5Core.so.5 #23 0x7f8b502b5a84 in () at /usr/lib/libQt5Core.so.5 #24 0x7f8b4c48b9be in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #25 0x7f8b4c48d831 in () at /usr/lib/libglib-2.0.so.0 #26 0x7f8b4c48d871 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #27 0x7f8b502b50d0 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #28 0x7f8b5025b57c in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #29 0x7f8b50263586 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #30 0x5650c1032bd5 in () #31 0x7f8b4fc2d023 in __libc_start_main () at /usr/lib/libc.so.6 #32 0x5650c10337ee in _start () [Inferior 1 (process 120878) detached] -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427387] New: Crash in ParseProjectJob::start() when exiting KDevelop soon after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427387
Bug ID: 427387
Summary: Crash in ParseProjectJob::start() when exiting
KDevelop soon after a large project is opened
Product: kdevelop
Version: git master
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: general
Assignee: kdevelop-bugs-n...@kde.org
Reporter: igor...@gmail.com
Target Milestone: ---
SUMMARY
When a user exits KDevelop soon after a large project is opened, before
ParseProjectJob::start() returns, DUChain::shutdown() may be called in the
ParseProjectJob::start()'s nested event loop. This causes a crash if the
ParseProjectJob is killed but not destroyed by the time its
QApplication::processEvents() returns and the start() indirectly accesses an
IndexedString.
SOFTWARE/OS VERSIONS
Manjaro GNU/Linux, Xfce
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
ADDITIONAL INFORMATION
I am going to create a Merge Request with a fix soon.
BACKTRACE
Application: KDevelop (kdevelop), signal: Aborted
[KCrash Handler]
#4 0x7f2d63043355 in raise () at /usr/lib/libc.so.6
#5 0x7f2d6302c853 in abort () at /usr/lib/libc.so.6
#6 0x7f2d6359b9ac in () at /usr/lib/libQt5Core.so.5
#7 0x7f2d6359ad59 in qt_assert_x(char const*, char const*, char const*,
int) () at /usr/lib/libQt5Core.so.5
#8 0x7f2d661dd67c in KDevelop::IndexedString::toUrl() const
(this=0x5565053195ac) at ../kdevplatform/serialization/indexedstring.cpp:304
#9 0x7f2d663c0c6a in (anonymous
namespace)::isValidURL(KDevelop::IndexedString const&) (url=...) at
../kdevplatform/language/backgroundparser/backgroundparser.cpp:97
#10 0x7f2d663c1887 in
KDevelop::BackgroundParser::addDocument(KDevelop::IndexedString const&,
KDevelop::TopDUContext::Features, int, QObject*,
QFlags, int)
(this=0x5564fc126170, url=...,
features=KDevelop::TopDUContext::VisibleDeclarationsAndContexts,
priority=1, notifyWhenReady=0x556503086fd0, flags=..., delay=-1) at
../kdevplatform/language/backgroundparser/backgroundparser.cpp:609
#11 0x7f2d663d9f44 in KDevelop::ParseProjectJob::start()
(this=0x556503086fd0) at
../kdevplatform/language/backgroundparser/parseprojectjob.cpp:184
#12 0x7f2d67628dd7 in KDevelop::RunController::registerJob(KJob*)
(this=0x5564fc11d360, job=0x556503086fd0) at
../kdevplatform/shell/runcontroller.cpp:628
#13 0x7f2d675e8711 in
KDevelop::ProjectController::reparseProject(KDevelop::IProject*, bool, bool)
(this=0x5564fc0bacd0, project=0x5564fdd0cfc0, forceUpdate=false,
forceAll=false) at ../kdevplatform/shell/projectcontroller.cpp:1381
#14 0x7f2d675e60b2 in
KDevelop::ProjectController::projectImportingFinished(KDevelop::IProject*)
(this=0x5564fc0bacd0, project=0x5564fdd0cfc0) at
../kdevplatform/shell/projectcontroller.cpp:1002
#15 0x7f2d675fe9b5 in KDevelop::ProjectPrivate::importDone(KJob*)
(this=0x5564fde1f4a0, job=0x5564ffb8de70) at
../kdevplatform/shell/project.cpp:221
#16 0x7f2d675fc232 in operator()(KJob*) const (__closure=0x5564ffe28840,
job=0x5564ffb8de70) at ../kdevplatform/shell/project.cpp:548
#17 0x7f2d675fe3a4 in QtPrivate::FunctorCall,
QtPrivate::List, void, KDevelop::Project::open(const
KDevelop::Path&):: >::call(struct {...} &, void **) (f=...,
arg=0x7ffee5c93e10) at /usr/include/qt/QtCore/qobjectdefs_impl.h:146
#18 0x7f2d675fe2fc in QtPrivate::Functor, 1>::call,
void>(struct {...} &, void *, void **) (f=..., arg=0x7ffee5c93e10) at
/usr/include/qt/QtCore/qobjectdefs_impl.h:256
#19 0x7f2d675fe2a1 in
QtPrivate::QFunctorSlotObject, 1, QtPrivate::List, void>::impl(int,
QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=1,
this_=0x5564ffe28830, r=0x5564fdd0cfc0, a=0x7ffee5c93e10, ret=0x0) at
/usr/include/qt/QtCore/qobjectdefs_impl.h:443
#20 0x7f2d637f4a26 in () at /usr/lib/libQt5Core.so.5
#21 0x7f2d63cafced in KJob::result(KJob*, KJob::QPrivateSignal) () at
/usr/lib/libKF5CoreAddons.so.5
#22 0x7f2d63cb080c in KJob::finishJob(bool) () at
/usr/lib/libKF5CoreAddons.so.5
#23 0x7f2d66159b9d in KDevelop::ExecuteCompositeJob::slotResult(KJob*)
(this=0x5564ffb8de70, job=0x55650008f780) at
../kdevplatform/util/executecompositejob.cpp:129
#24 0x7f2d637f4a26 in () at /usr/lib/libQt5Core.so.5
#25 0x7f2d63cafced in KJob::result(KJob*, KJob::QPrivateSignal) () at
/usr/lib/libKF5CoreAddons.so.5
#26 0x7f2d63cb080c in KJob::finishJob(bool) () at
/usr/lib/libKF5CoreAddons.so.5
#27 0x7f2d62f3e3e5 in
KDevelop::FileManagerListJob::handleResults(QList const&)
(this=0x55650008f780, entriesIn=...) at
../kdevplatform/project/filemanagerlistjob.cpp:196
#28 0x7f2d62f0a4f3 in
KDevelop::FileManagerListJob::qt_static_metacall(QObject*, QMetaObject::Call,
int, void**) (_o=0x55650008f780, _c=QMetaObject::InvokeMetaMethod, _id=4,
_a=0x7f2cf02c8798) at
[kdevelop] [Bug 427386] Segfault in ProjectController::reparseProject()=>...=>RunController::checkState() when exiting KDevelop soon after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427386 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Status|REPORTED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427387] Crash in ParseProjectJob::start() when exiting KDevelop soon after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427387 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Status|REPORTED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427386] Segfault in ProjectController::reparseProject()=>...=>RunController::checkState() when exiting KDevelop soon after a large project is opened
https://bugs.kde.org/show_bug.cgi?id=427386 Igor Kushnir changed: What|Removed |Added Summary|Segfault in |Segfault in |ProjectController::reparseP |ProjectController::reparseP |roject()=>...=>RunControlle |roject()=>...=>RunControlle |r::checkState() when|r::checkState() when |exiting KDevelop right |exiting KDevelop soon after |after a large project is|a large project is opened |opened | -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425994] Crashes caused by DebugController::showStepInSource() when a user requests KDevelop exit just before a code breakpoint is hit
https://bugs.kde.org/show_bug.cgi?id=425994 Igor Kushnir changed: What|Removed |Added Version Fixed In||5.6.1 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/300ea0 ||143f4dcf5537cac824e823bee1c ||e6077fc --- Comment #2 from Igor Kushnir --- Git commit 300ea0143f4dcf5537cac824e823bee1ce6077fc by Igor Kushnir. Committed on 15/10/2020 at 15:26. Pushed by igorkushnir into branch '5.6'. Do not open documents after DocumentController::cleanup() For now d->shuttingDown is checked in just one of many DocumentController::openDocument() overloads and alternatives, because this is the only overload that is known to be called after cleanup() and cause crashes. If similar crashes happen because of other ways of opening a document, the check can be moved or reused elsewhere. Or perhaps a different strategy will be needed to fix these hypothetical future crashes: e.g. simply returning nullptr doesn't work if the caller dereferences the returned document pointer without checking. FIXED-IN: 5.6.1 M +17 -0kdevplatform/shell/documentcontroller.cpp https://invent.kde.org/kdevelop/kdevelop/commit/300ea0143f4dcf5537cac824e823bee1ce6077fc -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425993] Crash in BreakpointModel::breakpoint() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425993 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/79c2b0 ||f65c258cb0d931f55aa417bb5cb ||8714ca1 Status|ASSIGNED|RESOLVED Version Fixed In||5.6.1 --- Comment #1 from Igor Kushnir --- Git commit 79c2b0f65c258cb0d931f55aa417bb5cb8714ca1 by Igor Kushnir. Committed on 15/10/2020 at 15:26. Pushed by igorkushnir into branch '5.6'. MIDebugger: check ICore::debugController() for nullptr When a user exits KDevelop while debugging a program, a queued call to MIDebugger::readyReadStandardOutput() may be invoked during or after ~CorePrivate(). If this happens after ~DebugController() (which is the parent of BreakpointModel), a crash is likely, because readyReadStandardOutput() indirectly calls MIBreakpointController::updateFromDebugger(), which assumes that BreakpointModel is not null (as do all other MIBreakpointController's member functions). Note that MIDebugger::readyReadStandardOutput() after ~DebugController() can be invoked both from inside ~MIDebugger() (more precisely, from inside the QProcess::waitForFinished() call) and before the destructor. There is no need to process a debugger's standard output and risk a crash when KDevelop has almost finished shutting down. FIXED-IN: 5.6.1 M +10 -0plugins/debuggercommon/midebugger.cpp https://invent.kde.org/kdevelop/kdevelop/commit/79c2b0f65c258cb0d931f55aa417bb5cb8714ca1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425986] Crash in BreakpointModel::save() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425986 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/c60e83 ||03829be4f13fd4511eda3d43655 ||72c74e6 Version Fixed In||5.6.1 --- Comment #1 from Igor Kushnir --- Git commit c60e8303829be4f13fd4511eda3d4365572c74e6 by Igor Kushnir. Committed on 15/10/2020 at 15:26. Pushed by igorkushnir into branch '5.6'. Check ICore::activeSession() for nullptr in BreakpointModel::save() When a user exits KDevelop while debugging a program, a queued call to BreakpointModel::save() may be invoked during Core::cleanup() or perhaps even during ~CorePrivate(). If this happens between SessionController::cleanup() and ~DebugController() (which is the parent of BreakpointModel), the result is a crash. A breakpoint change that is saved at this time is likely unimportant and can be safely skipped. FIXED-IN: 5.6.1 M +8-1kdevplatform/debugger/breakpoint/breakpointmodel.cpp https://invent.kde.org/kdevelop/kdevelop/commit/c60e8303829be4f13fd4511eda3d4365572c74e6 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425985] Crash in ~DebugSession() when exiting KDevelop during or shortly after debugging a program
https://bugs.kde.org/show_bug.cgi?id=425985 Igor Kushnir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/89ffdd ||c703cead3400122496d286f060b ||7dcce43 Resolution|--- |FIXED Version Fixed In||5.6.1 --- Comment #1 from Igor Kushnir --- Git commit 89ffddc703cead3400122496d286f060b7dcce43 by Igor Kushnir. Committed on 15/10/2020 at 15:26. Pushed by igorkushnir into branch '5.6'. MIDebugSession::m_plugin: raw pointer => QPointer When a user exits KDevelop during or shortly after debugging a program, a DebugSession object may outlive MIDebuggerPlugin. This can cause a crash in ~DebugSession(). Both GDB::DebugSession and LLDB::DebugSession already support nullptr m_plugin for testing purposes, so this QPointer type change alone eliminates the crash. FIXED-IN: 5.6.1 M +1-0plugins/debuggercommon/midebugsession.cpp M +2-1plugins/debuggercommon/midebugsession.h https://invent.kde.org/kdevelop/kdevelop/commit/89ffddc703cead3400122496d286f060b7dcce43 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425991] Crash in BreakpointModel::updateState() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425991 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||5.6.1 Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/37ff58 ||7ebe2a2c355d71cb583fb5f058c ||5301ff3 Status|ASSIGNED|RESOLVED --- Comment #1 from Igor Kushnir --- Git commit 37ff587ebe2a2c355d71cb583fb5f058c5301ff3 by Igor Kushnir. Committed on 15/10/2020 at 15:26. Pushed by igorkushnir into branch '5.6'. Safely finalize and destroy DebugSession objects DebugController is responsible for destroying debug sessions and it can not do so past its own destructor. Currently, depending on the relative timing of KDevelop exit and the 5 second interval of the singleshot timer in MIDebugSession::stopDebugger(), a DebugSession may be destroyed safely in time or not destroyed at all and possibly cause a crash by accessing the already destroyed DebugController or its children. Let us kill debugger processes and thus finalize the debug sessions' states in ~DebugController(). We delay the killing of debugger processes for as long as possible to give them a chance to exit on their own. Check ICore::documentController() for nullptr in BreakpointModel::updateMarks() and DebugController::clearExecutionPoint() to prevent crashes when these slots are invoked by DebugSession's state transition signals from inside ~DebugController(), which is called after ~DocumentController(). FIXED-IN: 5.6.1 M +9-2kdevplatform/debugger/breakpoint/breakpointmodel.cpp M +2-0kdevplatform/debugger/interfaces/idebugsession.h M +20 -2kdevplatform/shell/debugcontroller.cpp M +1-0kdevplatform/shell/debugcontroller.h M +5-0kdevplatform/tests/testdebugsession.cpp M +1-0kdevplatform/tests/testdebugsession.h M +17 -3plugins/debuggercommon/midebugsession.cpp M +4-0plugins/debuggercommon/midebugsession.h https://invent.kde.org/kdevelop/kdevelop/commit/37ff587ebe2a2c355d71cb583fb5f058c5301ff3 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425991] Crash in BreakpointModel::updateState() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425991 Igor Kushnir changed: What|Removed |Added Version Fixed In|5.6.1 |5.7.0 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425991] Crash in BreakpointModel::updateState() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425991 --- Comment #2 from Igor Kushnir --- Had to revert the fix in the stable 5.6 branch, because it broke the ABI. The commit is restored in the master branch, so I set Version Fixed In to 5.7.0. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425841] New: SIGPIPE, then a crash when the first event loop starts at least 60 seconds after KDevelop launch
https://bugs.kde.org/show_bug.cgi?id=425841 Bug ID: 425841 Summary: SIGPIPE, then a crash when the first event loop starts at least 60 seconds after KDevelop launch Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com Target Milestone: --- Created attachment 131205 --> https://bugs.kde.org/attachment.cgi?id=131205=edit KDevelop Frame Stack at SIGPIPE SUMMARY I have encountered this SIGPIPE followed by a crash many times while I debugged KDevelop. I have to hastily *Continue application execution* when breakpoints are hit during startup in order to circumvent the crash. But sometimes the crash just happens every other time (unless the "Session Crashed" dialog starts an event loop early). One temporary way out of this regular crashing is to speed up KDevelop startup by manually removing all [Working File Sets] entries from the affected session's sessionrc file. STEPS TO REPRODUCE 1. Open KDevelop project in KDevelop and build it with Debug build type. 2. Place a breakpoint in some function called during startup, for example at the beginning of BreakpointModel::scheduleSave(). 3. Debug Launch KDevelop. 4. When the breakpoint is hit, wait for some time before continuing execution (60 seconds is more than enough). 5. Disable the breakpoint or continue execution without waiting at subsequent breakpoint hits. OBSERVED RESULT The "*** Program received signal SIGPIPE (Broken pipe) ***" line appears in Debug tool view. The contents of the Frame Stack at this point is attached to the bug. When I press the *Continue application execution* button, KDevelop crashes with the following output in Debug tool view right after the SIGPIPE line quoted above (only the PID number varies, the rest of the output is constant): ICE default IO error handler doing an exit(), pid = 610216, errno = 32 register count: 0, destroy count: 0 *** Exited with return code: 01 *** EXPECTED RESULT The debugged KDevelop instance doesn't receive SIGPIPE signal and doesn't crash. SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION It appears that this is a general X11 (possibly Qt-specific) issue. A minimal reproduciple example and a fix are available at https://stackoverflow.com/questions/56686603/how-to-avoid-sigpipe-due-to-a-timeout-when-debugging-an-x11-program. I am going to create a Merge Request with this fix soon. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363237] Breakpoints (Breakpoints View) are not updated after removing/adding couple lines of code
https://bugs.kde.org/show_bug.cgi?id=363237 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #4 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #3) > Fixed in Bug 424431 Are you sure this bug is really fixed already? Even with the fix for Bug 424431, Breakpoints view only synchronizes when the document is saved. See https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 425993] New: Crash in BreakpointModel::breakpoint() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425993 Bug ID: 425993 Summary: Crash in BreakpointModel::breakpoint() when exiting KDevelop while debugging a program Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: CPP Debugger Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com CC: niko.s...@gmail.com Target Milestone: --- SUMMARY When a user exits KDevelop while debugging a program, a queued call to MIDebugger::readyReadStandardOutput() may be invoked during or after ~CorePrivate(). If this happens after ~DebugController() (which is the parent of BreakpointModel), a crash is likely, because readyReadStandardOutput() indirectly calls MIBreakpointController::updateFromDebugger(), which assumes that BreakpointModel is not null (as do all other MIBreakpointController's member functions). SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE (Debug) Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 0x7fd07528f340 in QScopedPointer >::operator->() const (this=0x10) at /usr/include/qt/QtCore/qscopedpointer.h:118 #5 0x7fd07528e72b in qGetPtrHelper > const>(QScopedPointer > const&) (ptr=...) at /usr/include/qt/QtCore/qglobal.h:1133 #6 0x7fd07528e602 in KDevelop::BreakpointModel::d_func() const (this=0x0) at ../kdevplatform/debugger/breakpoint/breakpointmodel.h:198 #7 0x7fd07528d5f9 in KDevelop::BreakpointModel::breakpoint(int) const (this=0x0, row=2) at ../kdevplatform/debugger/breakpoint/breakpointmodel.cpp:622 #8 0x7fd005a7e5ab in KDevMI::MIBreakpointController::updateFromDebugger(int, KDevMI::MI::Value const&, QFlags) (this=0x55a769ef2000, row=2, miBkpt=..., lockedColumns=...) at ../plugins/debuggercommon/mibreakpointcontroller.cpp:653 #9 0x7fd005a81310 in KDevMI::MIBreakpointController::InsertedHandler::handle(KDevMI::MI::ResultRecord const&) (this=0x55a76a6526b0, r=...) at ../plugins/debuggercommon/mibreakpointcontroller.cpp:140 #10 0x7fd005a5dfd9 in KDevMI::MI::MICommand::invokeHandler(KDevMI::MI::ResultRecord const&) (this=0x55a76485e000, r=...) at ../plugins/debuggercommon/mi/micommand.cpp:111 #11 0x7fd005a624e0 in KDevMI::MIDebugger::processLine(QByteArray const&) (this=0x55a769d389a0, line=...) at ../plugins/debuggercommon/midebugger.cpp:224 #12 0x7fd005a619e7 in KDevMI::MIDebugger::readyReadStandardOutput() (this=0x55a769d389a0) at ../plugins/debuggercommon/midebugger.cpp:147 #13 0x7fd005a65231 in QtPrivate::FunctorCall, QtPrivate::List<>, void, void (KDevMI::MIDebugger::*)()>::call(void (KDevMI::MIDebugger::*)(), KDevMI::MIDebugger*, void**) (f=(void (KDevMI::MIDebugger::*)(KDevMI::MIDebugger * const)) 0x7fd005a6190a , o=0x55a769d389a0, arg=0x7fff84c18200) at /usr/include/qt/QtCore/qobjectdefs_impl.h:152 #14 0x7fd005a64e1c in QtPrivate::FunctionPointer::call, void>(void (KDevMI::MIDebugger::*)(), KDevMI::MIDebugger*, void**) (f=(void (KDevMI::MIDebugger::*)(KDevMI::MIDebugger * const)) 0x7fd005a6190a , o=0x55a769d389a0, arg=0x7fff84c18200) at /usr/include/qt/QtCore/qobjectdefs_impl.h:185 #15 0x7fd005a6489e in QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55a769ccb270, r=0x55a769d389a0, a=0x7fff84c18200, ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:418 #16 0x7fd075acfa26 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7fff84c18200, r=0x55a769d389a0, this=0x55a769ccb270) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #17 doActivate(QObject*, int, void**) (sender=0x55a76a577d70, signal_index=15, argv=argv@entry=0x7fff84c18200) at kernel/qobject.cpp:3886 #18 0x7fd075ac8bc0 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=m@entry=0x7fd075d2cda0 , local_signal_index=local_signal_index@entry=6, argv=argv@entry=0x7fff84c18200) at kernel/qobject.cpp:3946 #19 0x7fd075a0430e in QProcess::readyReadStandardOutput(QProcess::QPrivateSignal) (this=, _t1=...) at .moc/moc_qprocess.cpp:367 #20 0x7fd075a09a56 in QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) (this=0x55a769b86ef0, channel=0x55a769b87000) at io/qprocess.cpp:1057 #21 0x7fd075a09fb5 in QProcessPrivate::_q_canReadStandardError() (this=) at io/qprocess.cpp:1084 #22 QProcess::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=, _c=, _id=, _a=0x7fff84c183b0) at .moc/moc_qprocess.cpp:210 #23 0x7fd075acfa60 in doActivate(QObject*, int, void**) (sender=0x55a76a56dd00, signal_index=3, argv=argv@entry=0x7fff84c183b0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:395 #24
[kdevelop] [Bug 425991] New: Crash in BreakpointModel::updateState() when exiting KDevelop while debugging a program
https://bugs.kde.org/show_bug.cgi?id=425991
Bug ID: 425991
Summary: Crash in BreakpointModel::updateState() when exiting
KDevelop while debugging a program
Product: kdevelop
Version: git master
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: CPP Debugger
Assignee: kdevelop-bugs-n...@kde.org
Reporter: igor...@gmail.com
CC: niko.s...@gmail.com
Target Milestone: ---
SUMMARY
When a user exits KDevelop while debugging a program, depending on the relative
timing of KDevelop exit and the 5 second interval of the singleshot timer in
MIDebugSession::stopDebugger(), a DebugSession may be destroyed safely in time
or not destroyed at all and possibly cause a crash by accessing the already
destroyed DebugController or its children. A DebugSession's state transition
signals lead to accesses to DebugController and its children, such as a call to
BreakpointModel::updateState(). Even though
IBreakpointController::breakpointModel() returns nullptr when ICore::self() is
nullptr, IBreakpointController::updateState() doesn't check for it. That is why
this=0x0 in BreakpointModel::updateState() in the backtrace below.
SOFTWARE/OS VERSIONS
Manjaro GNU/Linux, Xfce
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
ADDITIONAL INFORMATION
I am going to create a Merge Request with a fix soon.
BACKTRACE (Debug)
Application: KDevelop (kdevelop), signal: Segmentation fault
[KCrash Handler]
#4 0x7f38447fd190 in QScopedPointer >::operator->() const
(this=0x10) at /usr/include/qt/QtCore/qscopedpointer.h:118
#5 0x7f38447fc57b in
qGetPtrHelper >
const>(QScopedPointer > const&) (ptr=...) at
/usr/include/qt/QtCore/qglobal.h:1133
#6 0x7f38447fc442 in KDevelop::BreakpointModel::d_func() (this=0x0) at
../kdevplatform/debugger/breakpoint/breakpointmodel.h:198
#7 0x7f38447f9b3e in KDevelop::BreakpointModel::updateState(int,
KDevelop::Breakpoint::BreakpointState) (this=0x0, row=0,
state=KDevelop::Breakpoint::NotStartedState) at
../kdevplatform/debugger/breakpoint/breakpointmodel.cpp:326
#8 0x7f38447e4fcd in KDevelop::IBreakpointController::updateState(int,
KDevelop::Breakpoint::BreakpointState) (this=0x55c5920a9f10, row=0,
state=KDevelop::Breakpoint::NotStartedState) at
../kdevplatform/debugger/interfaces/ibreakpointcontroller.cpp:61
#9 0x7f37d2b7800b in
KDevMI::MIBreakpointController::debuggerStateChanged(KDevelop::IDebugSession::DebuggerState)
(this=0x55c5920a9f10, state=KDevelop::IDebugSession::EndedState) at
../plugins/debuggercommon/mibreakpointcontroller.cpp:301
#10 0x7f38447e7dea in QtPrivate::FunctorCall,
QtPrivate::List, void, void
(KDevelop::IBreakpointController::*)(KDevelop::IDebugSession::DebuggerState)>::call(void
(KDevelop::IBreakpointController::*)(KDevelop::IDebugSession::DebuggerState),
KDevelop::IBreakpointController*, void**) (f= table offset 120,
o=0x55c5920a9f10, arg=0x7ffe806e5750) at
/usr/include/qt/QtCore/qobjectdefs_impl.h:152
#11 0x7f38447e799b in QtPrivate::FunctionPointer::call,
void>(void
(KDevelop::IBreakpointController::*)(KDevelop::IDebugSession::DebuggerState),
KDevelop::IBreakpointController*, void**) (f= table offset 120,
o=0x55c5920a9f10, arg=0x7ffe806e5750) at
/usr/include/qt/QtCore/qobjectdefs_impl.h:185
#12 0x7f38447e72bc in QtPrivate::QSlotObject, void>::impl(int,
QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1,
this_=0x55c5a684ba10, r=0x55c5920a9f10, a=0x7ffe806e5750, ret=0x0) at
/usr/include/qt/QtCore/qobjectdefs_impl.h:418
#13 0x7f3845036a26 in () at /usr/lib/libQt5Core.so.5
#14 0x7f38447e3c27 in
KDevelop::IDebugSession::stateChanged(KDevelop::IDebugSession::DebuggerState)
(this=0x55c5c0f70b30, _t1=KDevelop::IDebugSession::EndedState) at
kdevplatform/debugger/KDevPlatformDebugger_autogen/include/moc_idebugsession.cpp:284
#15 0x7f37d2b65243 in
KDevMI::MIDebugSession::setSessionState(KDevelop::IDebugSession::DebuggerState)
(this=0x55c5c0f70b30, state=KDevelop::IDebugSession::EndedState) at
../plugins/debuggercommon/midebugsession.cpp:369
#16 0x7f37d2b661e7 in
KDevMI::MIDebugSession::handleDebuggerStateChange(QFlags,
QFlags) (this=0x55c5c0f70b30, oldState=..., newState=...)
at ../plugins/debuggercommon/midebugsession.cpp:499
#17 0x7f37d2b65506 in
KDevMI::MIDebugSession::setDebuggerState(QFlags)
(this=0x55c5c0f70b30, newState=...) at
../plugins/debuggercommon/midebugsession.cpp:410
#18 0x7f37d2b665d8 in operator()() const (__closure=0x55c5b06343f0) at
../plugins/debuggercommon/midebugsession.cpp:567
#19 0x7f37d2b6be54 in QtPrivate::FunctorCall,
QtPrivate::List<>, void, KDevMI::MIDebugSession::stopDebugger()::
>::call(struct {...} &, void **) (f=..., arg=0x7ffe806e5a00) at
/usr/include/qt/QtCore/qobjectdefs_impl.h:146
#20 0x7f37d2b6be26 in
QtPrivate::Functor,
0>::call, void>(struct {...} &, void *, void
[kdevelop] [Bug 425994] New: Crashes caused by DebugController::showStepInSource() when a user requests KDevelop exit just before a code breakpoint is hit
https://bugs.kde.org/show_bug.cgi?id=425994 Bug ID: 425994 Summary: Crashes caused by DebugController::showStepInSource() when a user requests KDevelop exit just before a code breakpoint is hit Product: kdevelop Version: git master Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: CPP Debugger Assignee: kdevelop-bugs-n...@kde.org Reporter: igor...@gmail.com CC: niko.s...@gmail.com Target Milestone: --- SUMMARY When a user exits KDevelop during debugging, a code breakpoint can be hit, and as a consequence DebugController::showStepInSource() be called in the event loop started by Core::cleanup() => BackgroundParser::waitForIdle(). Oblivious to the application state, DebugController then tries to open a document, which eventually results in a crash inside a slot connected to either ::textDocumentCreated or ::documentLoaded (these signals are emitted in the process of opening a document). SOFTWARE/OS VERSIONS Manjaro GNU/Linux, Xfce KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I am going to create a Merge Request with a fix soon. BACKTRACE 1 (Debug) Application: KDevelop (kdevelop), signal: Aborted [KCrash Handler] #4 0x7fb081ac2615 in raise () at /usr/lib/libc.so.6 #5 0x7fb081aab862 in abort () at /usr/lib/libc.so.6 #6 0x7fb0820209ac in qt_message_fatal (message=..., context=...) at global/qlogging.cpp:1914 #7 QMessageLogger::fatal(char const*, ...) const (this=this@entry=0x7ffd52ac7858, msg=msg@entry=0x7fb082326ea0 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:893 #8 0x7fb08201fd59 in qt_assert(char const*, char const*, int) (assertion=, file=, line=) at ../../include/QtCore/../../src/corelib/global/qlogging.h:90 #9 0x7fb081a37d9b in KDevelop::BreakpointModel::setupMovingCursor(KTextEditor::Document*, KDevelop::Breakpoint*) const (this=0x55d7e2d11c70, document=0x55d80c111610, breakpoint=0x55d7e2d77550) at ../kdevplatform/debugger/breakpoint/breakpointmodel.cpp:729 #10 0x7fb081a3489d in KDevelop::BreakpointModel::textDocumentCreated(KDevelop::IDocument*) (this=0x55d7e2d11c70, doc=0x55d7e4b96440) at ../kdevplatform/debugger/breakpoint/breakpointmodel.cpp:149 #11 0x7fb081a3a6b8 in QtPrivate::FunctorCall, QtPrivate::List, void, void (KDevelop::BreakpointModel::*)(KDevelop::IDocument*)>::call(void (KDevelop::BreakpointModel::*)(KDevelop::IDocument*), KDevelop::BreakpointModel*, void**) (f=(void (KDevelop::BreakpointModel::*)(KDevelop::BreakpointModel * const, KDevelop::IDocument *)) 0x7fb081a346dc , o=0x55d7e2d11c70, arg=0x7ffd52ac7b30) at /usr/include/qt/QtCore/qobjectdefs_impl.h:152 #12 0x7fb081a3a248 in QtPrivate::FunctionPointer::call, void>(void (KDevelop::BreakpointModel::*)(KDevelop::IDocument*), KDevelop::BreakpointModel*, void**) (f=(void (KDevelop::BreakpointModel::*)(KDevelop::BreakpointModel * const, KDevelop::IDocument *)) 0x7fb081a346dc , o=0x55d7e2d11c70, arg=0x7ffd52ac7b30) at /usr/include/qt/QtCore/qobjectdefs_impl.h:185 #13 0x7fb081a39d7c in QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55d7e2d11a80, r=0x55d7e2d11c70, a=0x7ffd52ac7b30, ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:418 #14 0x7fb082279a26 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffd52ac7b30, r=0x55d7e2d11c70, this=0x55d7e2d11a80) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #15 doActivate(QObject*, int, void**) (sender=0x55d7e2ca73c0, signal_index=8, argv=0x7ffd52ac7b30) at kernel/qobject.cpp:3886 #16 0x7fb084b76d0c in KDevelop::IDocumentController::textDocumentCreated(KDevelop::IDocument*) (this=0x55d7e2ca73c0, _t1=0x55d7e4b96440) at kdevplatform/interfaces/KDevPlatformInterfaces_autogen/EWIEGA46WW/moc_idocumentcontroller.cpp:451 #17 0x7fb084b80bca in KDevelop::IDocument::notifyTextDocumentCreated() (this=0x55d7e4b96440) at ../kdevplatform/interfaces/idocument.cpp:98 #18 0x7fb086084d26 in KDevelop::TextDocument::createViewWidget(QWidget*) (this=0x55d7e4b96420, parent=0x55d7ffb785f0) at ../kdevplatform/shell/textdocument.cpp:375 #19 0x7fb086086184 in KDevelop::TextView::createWidget(QWidget*) (this=0x55d80b5a3350, parent=0x55d7ffb785f0) at ../kdevplatform/shell/textdocument.cpp:631 #20 0x7fb084ce26a3 in Sublime::View::widget(QWidget*) (this=0x55d80b5a3350, parent=0x55d7ffb785f0) at ../kdevplatform/sublime/view.cpp:84 #21 0x7fb084cd6ec4 in Sublime::MainWindowPrivate::ViewCreator::operator()(Sublime::AreaIndex*) (this=0x7ffd52ac7fd0, index=0x55d7e2858b70) at ../kdevplatform/sublime/mainwindow_p.cpp:414 #22 0x7fb084cdcd87 in Sublime::Area::walkViewsInternal(Sublime::MainWindowPrivate::ViewCreator&, Sublime::AreaIndex*) (this=0x55d7e2858af0, op=...,
[kdevelop] [Bug 427109] Wrong pointer alignment type of KDELibs formatting style
https://bugs.kde.org/show_bug.cgi?id=427109 Igor Kushnir changed: What|Removed |Added Keywords||junior-jobs -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427109] Wrong pointer alignment type of KDELibs formatting style
https://bugs.kde.org/show_bug.cgi?id=427109 Igor Kushnir changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||igor...@gmail.com --- Comment #1 from Igor Kushnir --- Extremely easy to fix here: https://invent.kde.org/kdevelop/kdevelop/-/blob/6448782fbb6d1085e11357f84decfa90a63e8a34/plugins/astyle/astyle_formatter.cpp#L266 A test can be added here: https://invent.kde.org/kdevelop/kdevelop/-/blob/6448782fbb6d1085e11357f84decfa90a63e8a34/plugins/astyle/tests/test_astyle.cpp -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427109] Wrong pointer alignment type of KDELibs formatting style
https://bugs.kde.org/show_bug.cgi?id=427109 --- Comment #2 from Igor Kushnir --- Looks like this aspect of the KDELibs code style changed several years ago: Bug 265019. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 423651] KDevelop crashed during exit
https://bugs.kde.org/show_bug.cgi?id=423651 Igor Kushnir changed: What|Removed |Added Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 423651] KDevelop crashed during exit
https://bugs.kde.org/show_bug.cgi?id=423651 Igor Kushnir changed: What|Removed |Added Status|REPORTED|ASSIGNED Ever confirmed|0 |1 --- Comment #4 from Igor Kushnir --- An alternative backtrace for the same issue: Application: KDevelop (kdevelop), signal: Aborted [KCrash Handler] #4 0x7ff14d6d9615 in raise () at /usr/lib/libc.so.6 #5 0x7ff14d6c2862 in abort () at /usr/lib/libc.so.6 #6 0x7ff14dc379ac in qt_message_fatal (message=..., context=...) at global/qlogging.cpp:1914 #7 QMessageLogger::fatal(char const*, ...) const (this=this@entry=0x7fffe0b854b8, msg=msg@entry=0x7ff14df3dea0 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:893 #8 0x7ff14dc36d59 in qt_assert(char const*, char const*, int) (assertion=, file=, line=) at ../../include/QtCore/../../src/corelib/global/qlogging.h:90 #9 0x7ff15087e67c in KDevelop::IndexedString::toUrl() const (this=0x5626cf3aa6a0) at ../kdevplatform/serialization/indexedstring.cpp:304 #10 0x7ff0c4e52f85 in CTestFindJob::updateReady(KDevelop::IndexedString const&, KDevelop::ReferencedTopDUContext const&) (this=0x5626c31af660, document=..., context=...) at ../plugins/cmake/testing/ctestfindjob.cpp:83 #11 0x7ff0c4e4bef9 in CTestFindJob::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x5626c31af660, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x5626b5eabef8) at plugins/cmake/kdevcmakemanager_autogen/LLZHB5VKCH/moc_ctestfindjob.cpp:83 #12 0x7ff14de861d2 in QObject::event(QEvent*) (this=0x5626c31af660, e=0x5626b5eabeb0) at kernel/qobject.cpp:1314 #13 0x7ff14ece4702 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=, receiver=0x5626c31af660, e=0x5626b5eabeb0) at kernel/qapplication.cpp:3671 #14 0x7ff14de597ba in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x5626c31af660, event=0x5626b5eabeb0) at ../../include/QtCore/5.15.0/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:325 #15 0x7ff14de5c2a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=0x0, event_type=0, data=0x5626aefbc090) at kernel/qcoreapplication.cpp:1815 #16 0x7ff14deb2cf4 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x5626af08eb50) at kernel/qeventdispatcher_glib.cpp:277 #17 0x7ff14a21843c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #18 0x7ff14a2661d9 in () at /usr/lib/libglib-2.0.so.0 #19 0x7ff14a217221 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #20 0x7ff14deb2331 in QEventDispatcherGlib::processEvents(QFlags) (this=0x5626aefd09f0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #21 0x7ff14de5813c in QEventLoop::exec(QFlags) (this=this@entry=0x7fffe0b859b0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:141 #22 0x7ff14de605c4 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #23 0x5626ad13b81f in main(int, char**) (argc=3, argv=0x7fffe0b85e28) at ../app/main.cpp:850 [Inferior 1 (process 142157) detached] I have fixes for this and related crash in Bug 329246. Will create a merge request soon, after some testing. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 329246] Crash when project is closed before CTest evaluation finished
https://bugs.kde.org/show_bug.cgi?id=329246 Igor Kushnir changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED CC||igor...@gmail.com --- Comment #5 from Igor Kushnir --- Still happens in KDevelop 5.6.0. I have fixes for this and related crash in Bug 423651. Will create a merge request soon, after some testing. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 329246] Crash when project is closed before CTest evaluation finished
https://bugs.kde.org/show_bug.cgi?id=329246 Igor Kushnir changed: What|Removed |Added Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com Status|REOPENED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 423651] KDevelop crashed on exit before CTest evaluation finished
https://bugs.kde.org/show_bug.cgi?id=423651 Igor Kushnir changed: What|Removed |Added Summary|KDevelop crashed during |KDevelop crashed on exit |exit|before CTest evaluation ||finished -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 416874] KDevelop crashes when terminating a running program
https://bugs.kde.org/show_bug.cgi?id=416874 Igor Kushnir changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||5.6.1 Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/147add ||2ed8b3eac24b6bbd1af818f4685 ||ab2aced Status|ASSIGNED|RESOLVED --- Comment #11 from Igor Kushnir --- Git commit 147add2ed8b3eac24b6bbd1af818f4685ab2aced by Igor Kushnir. Committed on 22/09/2020 at 11:55. Pushed by igorkushnir into branch '5.6'. Don't crash after Cancel in Job Already Running dialog When a user Execute-Launches an application a second time while the previously launched instance of this application is still running, the "Job Already Running" dialog appears with 3 buttons. If a user clicks the Cancel button, a NativeAppJob kills itself Quietly. This NativeAppJob belongs to an ExecuteCompositeJob, which is not notified when a subjob is killed Quietly. So the ExecuteCompositeJob keeps waiting for it to finish. When this waiting ExecuteCompositeJob is killed (e.g. via "Stop All" button or on KDevelop exit), it attempts to kill the subjob it believes is still running, but which in fact is long since destroyed. This usually causes a segmentation fault. Aleix Pol fixed a similar crash when the "Kill All Instances" button in the "Job Already Running" dialog is clicked in 8430d3058f92725b4e6b7d85d8d68550ce12ee79. Related: bug 399511 FIXED-IN: 5.6.1 M +1-1plugins/execute/nativeappjob.cpp https://invent.kde.org/kdevelop/kdevelop/commit/147add2ed8b3eac24b6bbd1af818f4685ab2aced -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 399511] Kdevelop crashed when closing
https://bugs.kde.org/show_bug.cgi?id=399511 Igor Kushnir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version Fixed In||5.6.1 Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/147add ||2ed8b3eac24b6bbd1af818f4685 ||ab2aced Resolution|--- |FIXED --- Comment #3 from Igor Kushnir --- Git commit 147add2ed8b3eac24b6bbd1af818f4685ab2aced by Igor Kushnir. Committed on 22/09/2020 at 11:55. Pushed by igorkushnir into branch '5.6'. Don't crash after Cancel in Job Already Running dialog When a user Execute-Launches an application a second time while the previously launched instance of this application is still running, the "Job Already Running" dialog appears with 3 buttons. If a user clicks the Cancel button, a NativeAppJob kills itself Quietly. This NativeAppJob belongs to an ExecuteCompositeJob, which is not notified when a subjob is killed Quietly. So the ExecuteCompositeJob keeps waiting for it to finish. When this waiting ExecuteCompositeJob is killed (e.g. via "Stop All" button or on KDevelop exit), it attempts to kill the subjob it believes is still running, but which in fact is long since destroyed. This usually causes a segmentation fault. Aleix Pol fixed a similar crash when the "Kill All Instances" button in the "Job Already Running" dialog is clicked in 8430d3058f92725b4e6b7d85d8d68550ce12ee79. Related: bug 416874 FIXED-IN: 5.6.1 M +1-1plugins/execute/nativeappjob.cpp https://invent.kde.org/kdevelop/kdevelop/commit/147add2ed8b3eac24b6bbd1af818f4685ab2aced -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 416874] KDevelop crashes when terminating a running program
https://bugs.kde.org/show_bug.cgi?id=416874 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #10 from Igor Kushnir --- This crash can be reproduced reliably with the following steps: 1. Execute-Launch an application from KDevelop. 2. Repeat the 1st step with the same application while the previous instance is still running. 3. In the "Job Already Running" dialog that appears after the 2nd step click the Cancel button. 4. Press the "Stop All" button. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 399511] Kdevelop crashed when closing
https://bugs.kde.org/show_bug.cgi?id=399511 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #2 from Igor Kushnir --- This crash can be reproduced reliably with the following steps: 1. Execute-Launch an application from KDevelop. 2. Repeat the 1st step with the same application while the previous instance is still running. 3. In the "Job Already Running" dialog that appears after the 2nd step click the Cancel button. 4. (optional) Exit the still running first application instance. 5. Exit KDevelop. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427157] Crash when enabling Unit Tests tool view after closing a project with tests
https://bugs.kde.org/show_bug.cgi?id=427157 Igor Kushnir changed: What|Removed |Added Summary|Crash opening unit test |Crash when enabling Unit |view|Tests tool view after ||closing a project with ||tests Assignee|kdevelop-bugs-n...@kde.org |igor...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427157] Crash opening unit test view
https://bugs.kde.org/show_bug.cgi?id=427157 Igor Kushnir changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||igor...@gmail.com --- Comment #1 from Igor Kushnir --- Steps to reproduce: 1. Disable Unit Tests tool view. 2. Open a project that contains CTest tests. 3. Wait for a little while to let KDevelop's BackgroundParser parse several unit tests. 4. Close the project. 5. Enable Unit Tests tool view. The issue is that when a project is closed and destroyed, its test suites are not removed from TestControllerPrivate::suites. CTestSuite::project() returns a dangling pointer then. This is both a memory leak and, as can be seen from this crash report, a source of other bugs. I've fixed this issue by overhauling the KDevelop's test suite code, though I haven't thought about the possibility of this crash when I was doing it. Just checked: yes, this crash is fixed by my changes. When I complete my large overhaul/fix, I'll create a merge request. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427157] Crash when enabling Unit Tests tool view after closing a project with tests
https://bugs.kde.org/show_bug.cgi?id=427157 Igor Kushnir changed: What|Removed |Added Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 397062] missing Qt5 QDebug output
https://bugs.kde.org/show_bug.cgi?id=397062 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com --- Comment #8 from Igor Kushnir --- Created attachment 131727 --> https://bugs.kde.org/attachment.cgi?id=131727=edit [PATCH] Execute Launch: show Qt log output in Run tool view I have spent several hours testing when the output appears or not until I found this bug report. This bug only happens if KDevelop itself is started from a graphical environment rather than from a terminal, and the user launches a Qt application via "Execute Launch" KDevelop action rather than "Debug Launch" action. The issue is inherited by another KDevelop instance Execute-Launched from KDevelop (a recursion of sorts). I just implemented a fix for this issue that sets QT_FORCE_STDERR_LOGGING to 1 in the initial default environment profile and when the user creates a new environment profile: see the attached 0001-Execute-Launch-show-Qt-log-output-in-Run-tool-view.patch. However now I realize that a better fix is possible: add a checkbox on Launch Configuration page with text "Show Qt log messages in Run tool view" and a tooltip "Sets QT_FORCE_STDERR_LOGGING environment variable to 1" (or maybe a more detailed explanation in the tooltip). The checkbox should be checked by default. When KDevelop applies the selected environment profile to a launched program and this new option in its launch configuration is on, it will silently set one more hidden environment variable. This way the fix is retroactively applied to all existing launch configurations without the need to manually add the environment variable to all environment profiles configured in the past. Plus the checkbox provides an opportunity to explain why the environment variable is needed, as opposed to simply specifying it in the unconfigured default and new environment profiles. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 --- Comment #12 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #11) > Yes. I agree, but there are users, like me, who don't use set formatting > style, at all. I never called 'reformat code' function in KDevelop. Normally > I format code manually, because no one existing (by default in KDevelop) > formatting style doesn't match my expectation. So my format of code isn't > like KDevelop thinks like it is and in result breaks it. That would mean > this isn't a bug and every user should use 'reformat code' before calling > "Rename assistant". > > Maybe is possible to define own formatting. I mean define where should be > space, and where not, or indention in new line, etc. Of course it is possible. There are actually several ways to do this: 1. You can create a new style based on an existing Artistic Style (the *New* button on the Source Formatter tab of KDevelop Settings), then edit the style in a dedicated dialog (the *Edit* button on the same tab). 2. You can switch to a Custom Script Formatter, choose *uncrustify* or *clang-format* and configure these tools via their specific configuration files and command line arguments. 3. There is even a dedicated tool distributed with KDevelop: kdev_format_source. Read the tool's description by selecting *KDevelop: kdev_format_source* on the Source Formatter tab. You can use KDevelop's own formatting configuration as a starting point for your preferred style: https://commits.kde.org/kdevelop/kdevelop?path=format_sources and https://commits.kde.org/kdevelop/kdevelop?path=format.config.uncrustify. If none of these tools supports your formatting preferences, you can disable formatting altogether by selecting the *KDevelop: kdev_format_source* formatter for the programming languages you use and not providing the kdev_format_source file. In this case no reformatting will be applied to your code. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 --- Comment #13 from Igor Kushnir --- There are screenshots of the Artistic Style customization dialog in the KDevelop user documentation: https://userbase.kde.org/KDevelop5/Manual/Customizing_KDevelop#Customizing_code_indentation -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 --- Comment #16 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #15) > Thanks a lot for suggestions. They were very helpful. You are welcome! > I applied your last advise, where you told how to skip formatting. This was > what I needed. > I think I could close this ticket marking it as "Not a bug". Of course only > if anybody has nothing against. I am not sure this is not a bug. Whoever closes it should verify that when a style that matches the actual formatting is selected, the issue is gone. And even if this is indeed the case, I think we should better document when KDevelop applies formatting to the code, and how to configure formatting styles. If we document this well enough in the application itself, we may succeed in preventing such non-bugs from being reported in the future. After all, both you and Jaka were hit by this same issue. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 --- Comment #18 from Igor Kushnir --- (In reply to Piotr Mierzwinski from comment #17) > Just found the issue, where your suggestion about skipping formatting > doesn't work how we expected. > Namely, in case of 'Adapt signature', where I supposed that formatting is > applied automatically I wanted to skip it so I set kdev_format_source > without linked file. And unfortunately formatting happened partially. I mean > that in this case indicator of reference or pointer was moved next to type, > if originally was present next to name of argument. > I made test with updating definition of method and in declaration these > indicators were modified, but space didn't touch. I suppose this is exactly what I surmised in an earlier comment: > In case when more code is generated, KDevelop must ensure > that it is not formatted in some fixed-for-all-IDE-users style chosen by > KDevelop > developers, but in the style the user selected for the current > session/project. Probably KDevelop generates new code for your signature in a predefined hard-coded style, then tries to format it in your chosen style and fails, leaving the signature in the hard-coded style. Please try to configure Artistic Style, uncrustify, clang-format or kdev_format_source to match your code formatting as I suggested in my long comment above. See if KDevelop's formatting matches your expectations then. Or is your code formatted so heterogeneously and unsystematically that even fine-grained kdev_format_source configuration is very time-consuming/impossible? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427227] kdevelop parser crashes with SEGFAULT
https://bugs.kde.org/show_bug.cgi?id=427227 --- Comment #10 from Igor Kushnir --- (In reply to Mate Soos from comment #9) > Ah! Nce! Sorry, I was somehow convinced it must be my wrong setup > somehow that made the UI crash under GDB. That crash was making it *really* > hard for me to submit a backtrace, to be honest, so I'd be really happy if > it was fixed! Thanks for picking that up, that's great news! > > I added myself to the CC list of bug > https://bugs.kde.org/show_bug.cgi?id=427246 so I will be notified. Thanks > again! I am happy to help with traces, if needed. > > Cheers, > > Mate The GDB crash is already fixed in Qt, but not yet released. I've found it and added a comment with the fix description under Bug 427246 before I wrote my second comment here. So you won't be notified about that comment since you just subscribed to the issue :) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427246] SIGTRAP/SIGSEGV while running any version of KDevelop under GDB after a recent system update
https://bugs.kde.org/show_bug.cgi?id=427246 --- Comment #3 from Igor Kushnir --- (In reply to Francis Herne from comment #2) > As I mentioned on the other bug, one workaround is to start KDevelop and > then use `gdb --pid=`. I haven't tried this workaround from the command line, but attaching to a KDevelop process from another KDevelop instance/session didn't work well for me: once a code breakpoint was hit, the debugged instance received SIGTRAP/SIGSEGV signals and eventually crashed. With the patched Qt attaching from KDevelop works fine. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427246] SIGTRAP/SIGSEGV while running any version of KDevelop under GDB after a recent system update
https://bugs.kde.org/show_bug.cgi?id=427246
--- Comment #1 from Igor Kushnir ---
FAILED WORKAROUND
Add the following two lines to /etc/security/limits.conf and reboot:
* hardnofile 10 # necessary for KDevelop
* softnofile 10 # necessary for KDevelop
This workaround does not change anything.
INADEQUATE WORKAROUND
Narrowed down the plugins that must be disabled in
~/.local/share/kdevelop/sessions/{}/sessionrc to enable launching,
hitting breakpoints in the KDevelop source code and exiting KDevelop without
crashes: KDevCMakeDocumentation, kdevfilemanager, kdevqthelp (I have
kdevperforce and katectagsplugin disabled too, but not sure if that's
necessary). In addition, I had to force-disable kdevclangsupport plugin via
`export KDEV_DISABLE_PLUGINS=kdevclangsupport`. Even without these essential
plugins, opening a project triggers the signals and crashes.
FIX
This is a known Qt 5.15.1 bug: QTBUG-86319 (I found a duplicate of this bug by
searching for "SIGTRAP" on the Qt bug tracker). The corresponding Arch Linux
bug: https://bugs.archlinux.org/task/68001. I applied the fix for the Qt bug
from https://codereview.qt-project.org/c/qt/qtbase/+/314049 and the signals and
crashes are gone!
The fix will be included in Qt 5.15.2. In the meantime, it would be useful if
the qt5-base Arch Linux package included the patch to spare developers from
manually applying the fix after each qt5-base pkgrel update. @{Arch Linux users
affected by this bug}, please create an issue on the Arch bug tracker or reopen
FS#68001 (closed because this turned out to be not a GDB issue) and request the
qt5-base patch.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 427227] kdevelop parser crashes with SEGFAULT
https://bugs.kde.org/show_bug.cgi?id=427227 --- Comment #8 from Igor Kushnir --- Mate, I commented about another non-Python bug - the GDB crash, which you and Francis have also discussed here. I've found the relevant Qt bug and the fix for the GDB crash. Described them in a comment to Bug 427246. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 427288] CMake is run frequently, but always switches to the Build tool view, hiding the Konsole.
https://bugs.kde.org/show_bug.cgi?id=427288 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Igor Kushnir --- Yes, this behavior annoys me too. Patches welcome! -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 316873] no UI for fetching more frames in the framestack
https://bugs.kde.org/show_bug.cgi?id=316873 Igor Kushnir changed: What|Removed |Added CC||igor...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 317299] Rename assistant (for local variable) broke indents when we using Tabs as indent
https://bugs.kde.org/show_bug.cgi?id=317299 --- Comment #10 from Igor Kushnir --- > Yes. It might be some workaround this issue, but not solves the problem. > I wonder why in moment of using "Rename assistant" is applying automatic > formatting of code, whereas I didn't call it intentionally. If I will want > to reformat my code in some style then I will use formatting option in > KDevelop menu. > > Therefore maybe some solution could be just skipping formatting of code in > "Rename assistant", if this is possible. And alternatively adding option in > configuration forcing usage of formatting. I am afraid this is not so simple. In many cases KDevelop generates more complex code than simply renaming, and the code path is likely shared by different-complexity refactorings. In case when more code is generated, KDevelop must ensure that it is not formatted in some fixed-for-all-IDE-users style chosen by KDevelop developers, but in the style the user selected for the current session/project. *Disclaimer: I am not sure about this as it has been some months since I dived into the relevant code.* -- You are receiving this mail because: You are watching all bug changes.
