Application: kdevelop (5.7.211202 (21.12.2)) Qt Version: 5.15.3 Frameworks Version: 5.96.0 Operating System: Linux 5.18.10-200.fc36.x86_64 x86_64 Windowing System: X11 Distribution: Fedora Linux 36 (KDE Plasma) DrKonqi: 5.25.2 [KCrashBackend] -- Information about the crash: Kdevelop crashes when I attempt to invoke it via krunner and konsole via bash: [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ kdevelop kdevplatform.serialization: version mismatch or no version hint; expected version: 138412547 kdevplatform.serialization: "The data-repository at /home/BEEDELLROKEJULIANLOCKHART/.cache/kdevduchain/kdevelop-{e2b22691-afda-4809-9307-e53e0ff58f7c} has to be cleared." Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication. Program to run not set. No command line arguments specified. KCrash: Application 'kdevelop' crashing... KCrash: Attempting to start /usr/libexec/drkonqi QSocketNotifier: Invalid socket 8 and type 'Read', disabling... QSocketNotifier: Invalid socket 57 and type 'Read', disabling... [1]+ Stopped kdevelop [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ krunner [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ Unable to find file for pid 31409 expected at "kcrash-metadata/31409.ini" ^C [1]+ Exit 253 kdevelop krunner's output is weird. The crash can be reproduced every time. -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 0x00007f806751642f in GrepOutputView::renewModel(GrepJobSettings const&, QString const&) () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #5 0x00007f8067512132 in GrepDialog::startSearch() () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #6 0x00007f80f8357694 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #7 0x00007f80f8ff5c82 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #8 0x00007f80f832d658 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #9 0x00007f80f83309b4 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5 #10 0x00007f80f837e807 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5 #11 0x00007f80f49b9faf in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #12 0x00007f80f4a0f2c8 in g_main_context_iterate.constprop () from /lib64/libglib-2.0.so.0 #13 0x00007f80f49b7940 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #14 0x00007f80f837e2fa in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5 #15 0x00007f80f832c0ba in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5 #16 0x00007f80f86c6835 in KJob::exec() () from /lib64/libKF5CoreAddons.so.5 #17 0x00007f8066e33922 in Kasten::JobManager::executeJob(KJob*) () from /lib64/libKasten4Core.so.0 #18 0x00007f806706b2ef in KDevelop::OktetaDocument::newView(Sublime::Document*) () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevokteta.so #19 0x00007f80f68dd91d in Sublime::Document::createView() () from /lib64/libKDevPlatformSublime.so.57 #20 0x00007f80f9cc9c07 in (anonymous namespace)::loadToAreaPrivate(Sublime::Area*, Sublime::AreaIndex*, KConfigGroup const&, QMultiMap<QString, Sublime::View*>&) [clone .lto_priv.0] () from /lib64/libKDevPlatformShell.so.57 #21 0x00007f80f9cd1c4d in KDevelop::WorkingSet::loadToArea(Sublime::Area*) () from /lib64/libKDevPlatformShell.so.57 #22 0x00007f80f9cc898c in KDevelop::WorkingSetController::changedWorkingSet(Sublime::Area*, Sublime::Area*, QString const&, QString const&) () from /lib64/libKDevPlatformShell.so.57 #23 0x00007f80f8360c36 in void doActivate<false>(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #24 0x00007f80f68cbc2e in Sublime::Area::changedWorkingSet(Sublime::Area*, Sublime::Area*, QString const&, QString const&) () from /lib64/libKDevPlatformSublime.so.57 #25 0x00007f80f68cfbe6 in Sublime::Area::setWorkingSet(QString const&, bool, Sublime::Area*) () from /lib64/libKDevPlatformSublime.so.57 #26 0x00007f80f9c33471 in KDevelop::UiController::loadAllAreas(QExplicitlySharedDataPointer<KSharedConfig> const&) () from /lib64/libKDevPlatformShell.so.57 #27 0x00007f80f9c372dd in KDevelop::CorePrivate::initialize(KDevelop::Core::Setup, QString const&) () from /lib64/libKDevPlatformShell.so.57 #28 0x00007f80f9c3815e in KDevelop::Core::initialize(KDevelop::Core::Setup, QString const&) () from /lib64/libKDevPlatformShell.so.57 #29 0x00005590b50c7876 in main () [Inferior 1 (process 19889) detached] Reported using DrKonqi
Created attachment 150657 [details] New crash information added by DrKonqi kdevelop (5.7.211202 (21.12.2)) using Qt 5.15.3 drkonqi solely appears when kdevelop is invoked via krunner rather than konsole. -- Backtrace (Reduced): #4 0x00007f033a31742f in GrepOutputView::renewModel(GrepJobSettings const&, QString const&) () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #5 0x00007f033a313132 in GrepDialog::startSearch() () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #6 0x00007f03bb519694 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #7 0x00007f03bc1b7c82 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #8 0x00007f03bb4ef658 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5
Created attachment 150658 [details] New crash information added by DrKonqi kdevelop (5.7.211202 (21.12.2)) using Qt 5.15.3 [root@1656943212 BEEDELLROKEJULIANLOCKHART]# dnf upgrade --refresh -y Fedora 36 - x86_64 68 kB/s | 21 kB 00:00 Fedora 36 - x86_64 - Debug 135 kB/s | 19 kB 00:00 Fedora 36 - Source 256 kB/s | 18 kB 00:00 Fedora 36 openh264 (From Cisco) - x86_64 9.6 kB/s | 989 B 00:00 Fedora 36 openh264 (From Cisco) - x86_64 - Debug 14 kB/s | 997 B 00:00 Fedora Modular 36 - x86_64 267 kB/s | 21 kB 00:00 Fedora Modular 36 - x86_64 - Debug 246 kB/s | 18 kB 00:00 Fedora Modular 36 - Source 151 kB/s | 18 kB 00:00 Fedora 36 - x86_64 - Updates 157 kB/s | 20 kB 00:00 Fedora 36 - x86_64 - Updates - Debug 234 kB/s | 18 kB 00:00 Fedora 36 - Updates Source 248 kB/s | 18 kB 00:00 Fedora Modular 36 - x86_64 - Updates 146 kB/s | 20 kB 00:00 Fedora Modular 36 - x86_64 - Updates - Debug 226 kB/s | 17 kB 00:00 Fedora Modular 36 - Updates Source 139 kB/s | 18 kB 00:00 Fedora 36 - x86_64 - Test Updates 138 kB/s | 20 kB 00:00 Fedora 36 - x86_64 - Test Updates Debug 230 kB/s | 19 kB 00:00 Fedora 36 - Test Updates Source 219 kB/s | 18 kB 00:00 Fedora Modular 36 - x86_64 - Test Updates 139 kB/s | 19 kB 00:00 Fedora Modular 36 - x86_64 - Test Updates Debug 129 kB/s | 18 kB 00:00 Fedora Modular 36 - Test Updates Source 139 kB/s | 17 kB 00:00 packages-microsoft-com-prod 19 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 36 - Free 30 kB/s | 7.8 kB 00:00 RPM Fusion for Fedora 36 - Free - Updates 55 kB/s | 6.8 kB 00:00 Dependencies resolved. Nothing to do. Complete! [root@1656943212 BEEDELLROKEJULIANLOCKHART]# -- Backtrace (Reduced): #4 0x00007fb0ed42442f in GrepOutputView::renewModel(GrepJobSettings const&, QString const&) () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #5 0x00007fb0ed420132 in GrepDialog::startSearch() () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #6 0x00007fb166634694 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #7 0x00007fb1672d2c82 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #8 0x00007fb16660a658 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5
Created attachment 150659 [details] New crash information added by DrKonqi kdevelop (5.7.211202 (21.12.2)) using Qt 5.15.3 [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ script -a Script started, output log file is 'typescript'. [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ kdevelop Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication. Program to run not set. No command line arguments specified. KCrash: Application 'kdevelop' crashing... KCrash: Attempting to start /usr/libexec/drkonqi QSocketNotifier: Invalid socket 8 and type 'Read', disabling... QSocketNotifier: Invalid socket 55 and type 'Read', disabling... [1]+ Stopped kdevelop [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ Unable to find file for pid 2406 expected at "kcrash-metadata/2406.ini" [BEEDELLROKEJULIANLOCKHART@1656943212 ~]$ -- Backtrace (Reduced): #4 0x00007f0e06e0642f in GrepOutputView::renewModel(GrepJobSettings const&, QString const&) () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #5 0x00007f0e06e02132 in GrepDialog::startSearch() () from /usr/lib64/qt5/plugins/kdevplatform/35/kdevgrepview.so #6 0x00007f0e97c90694 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #7 0x00007f0e9892ec82 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #8 0x00007f0e97c66658 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5
I am certain that I thought that those traces were different. I apologize for the spam.
Is this a recent regression? Could you try a new session? `kdevelop -n test-session` Can you provide debug symbols? Either recompile KDevelop with debug symbols or use https://fedoraproject.org/wiki/Debuginfod
"kdevelop -n test-session" correctly invokes kdevelop, and now kdevelop appears to invoke correctly. Should this report be closed because this was somehow caused by me, or should I attempt to provide some debug-information to you?
Although probably irrelevant to this problem, "http://stackoverflow.com/questions/56159475" might be useful if "Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication" is unintentional.
(In reply to BEEDELL ROKE JULIAN LOCKHART from comment #6) > "kdevelop -n test-session" correctly invokes kdevelop, and now kdevelop > appears to invoke correctly. Should this report be closed because this was > somehow caused by me, or should I attempt to provide some debug-information > to you? KDevelop remembers a last used session. I suppose if you open the previous session from KDevelop's main menu=>Session, you'll see the same crash again. Hard to tell what caused the session corruption and there are plenty more crashes to fix. I'll close this bug. Reopen when another session gets corrupted like this in the future.
(In reply to Igor Kushnir from comment #8) > (In reply to BEEDELL ROKE JULIAN LOCKHART from comment #6) > > "kdevelop -n test-session" correctly invokes kdevelop, and now kdevelop > > appears to invoke correctly. Should this report be closed because this was > > somehow caused by me, or should I attempt to provide some debug-information > > to you? > KDevelop remembers a last used session. I suppose if you open the previous > session from KDevelop's main menu=>Session, you'll see the same crash again. > Hard to tell what caused the session corruption and there are plenty more > crashes to fix. I'll close this bug. Reopen when another session gets > corrupted like this in the future. Because of what you said, I created a new session by invoking “kdevelop -n”. It operated. I subsequently deleted that session, and kdevelop correctly allowed me to continue with the previously created test-session. That session operated. However, if I attempt to switch to the “Default:” session, the session-corruption dialogue with the “Clear cache” button appears the first time, and does not appear the subsequent times, yet I remain unable to switch to the default session. If I delete all alternative sessions so that solely the default sessions remain, KDevelop becomes unable to launch, obviously because the default session is corrupt. Even “su -c "dnf reinstall --refresh -y 'kdevelop'"” does not remediate the problem. However, invocation of the graphical session-chooser (“kdevelop --ps”) or textual creation of a new session via “kdevelop -n” allows me to utilize kdevelop, but this may be problematic for new users. I expect that even this is not enough information for you to remediate this problem, but might this be worth reporting to Red Hat?
(In reply to BEEDELL ROKE JULIAN LOCKHART from comment #9) > (In reply to Igor Kushnir from comment #8) > > (In reply to BEEDELL ROKE JULIAN LOCKHART from comment #6) > > > "kdevelop -n test-session" correctly invokes kdevelop, and now kdevelop > > > appears to invoke correctly. Should this report be closed because this was > > > somehow caused by me, or should I attempt to provide some debug-information > > > to you? > > KDevelop remembers a last used session. I suppose if you open the previous > > session from KDevelop's main menu=>Session, you'll see the same crash again. > > Hard to tell what caused the session corruption and there are plenty more > > crashes to fix. I'll close this bug. Reopen when another session gets > > corrupted like this in the future. > > Because of what you said, I created a new session by invoking “kdevelop -n”. > It operated. I subsequently deleted that session, and kdevelop correctly > allowed me to continue with the previously created test-session. That > session operated. However, if I attempt to switch to the “Default:” session, > the session-corruption dialogue with the “Clear cache” button appears the > first time, and does not appear the subsequent times, yet I remain unable to > switch to the default session. If I delete all alternative sessions so that > solely the default sessions remain, KDevelop becomes unable to launch, > obviously because the default session is corrupt. > > Even “su -c "dnf reinstall --refresh -y 'kdevelop'"” does not remediate the > problem. However, invocation of the graphical session-chooser (“kdevelop > --ps”) or textual creation of a new session via “kdevelop -n” allows me to > utilize kdevelop, but this may be problematic for new users. > > I expect that even this is not enough information for you to remediate this > problem, but might this be worth reporting to Red Hat? This is not a packaging problem. Nothing worth reporting to Red Hat. The default session files have been corrupted on your system for some reason. You can "fix" your Default session by removing its directory in ~/.local/share/kdevelop/sessions
(In reply to Igor Kushnir from comment #10) > (In reply to BEEDELL ROKE JULIAN LOCKHART from comment #9) > > (In reply to Igor Kushnir from comment #8) > > > (In reply to BEEDELL ROKE JULIAN LOCKHART from comment #6) > > > > "kdevelop -n test-session" correctly invokes kdevelop, and now kdevelop > > > > appears to invoke correctly. Should this report be closed because this was > > > > somehow caused by me, or should I attempt to provide some debug-information > > > > to you? > > > KDevelop remembers a last used session. I suppose if you open the previous > > > session from KDevelop's main menu=>Session, you'll see the same crash again. > > > Hard to tell what caused the session corruption and there are plenty more > > > crashes to fix. I'll close this bug. Reopen when another session gets > > > corrupted like this in the future. > > > > Because of what you said, I created a new session by invoking “kdevelop -n”. > > It operated. I subsequently deleted that session, and kdevelop correctly > > allowed me to continue with the previously created test-session. That > > session operated. However, if I attempt to switch to the “Default:” session, > > the session-corruption dialogue with the “Clear cache” button appears the > > first time, and does not appear the subsequent times, yet I remain unable to > > switch to the default session. If I delete all alternative sessions so that > > solely the default sessions remain, KDevelop becomes unable to launch, > > obviously because the default session is corrupt. > > > > Even “su -c "dnf reinstall --refresh -y 'kdevelop'"” does not remediate the > > problem. However, invocation of the graphical session-chooser (“kdevelop > > --ps”) or textual creation of a new session via “kdevelop -n” allows me to > > utilize kdevelop, but this may be problematic for new users. > > > > I expect that even this is not enough information for you to remediate this > > problem, but might this be worth reporting to Red Hat? > This is not a packaging problem. Nothing worth reporting to Red Hat. The > default session files have been corrupted on your system for some reason. > You can "fix" your Default session by removing its directory in > ~/.local/share/kdevelop/sessions Problem remediated. Thanks a lot.
I see the same error, an here is what I get as backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 GrepOutputView::renewModel(GrepJobSettings const&, QString const&) (this=this@entry=0x0, settings=..., description=...) at /usr/src/debug/kdevelop5-22.08.3-lp153.33.1.x86_64/plugins/grepview/grepoutputview.cpp:212 #5 0x00007f2ef901a131 in GrepDialog::startSearch() (this=<optimized out>) at /usr/src/debug/kdevelop5-22.08.3-lp153.33.1.x86_64/plugins/grepview/grepdialog.cpp:530 From looking at the code it seems to me that nothing ever checks that "toolview" is not nullptr, which seems to correspong with this being nullptr on the next call.
A possible workaround is to show an error message via IUiController::postMessage() and early-return if toolView is null. Though it would be good to know why it is null in the first place. GrepDialog asks to create the tool view. Does this happen too early, before all areas are loaded? Why? When I activate the "Find/Replace in Files..." action shortcut repeatedly while launching KDevelop, I cannot reproduce this crash. The only place that I found where the search dialog is not shown and GrepDialog::startSearch() is called immediately (show == false is passed to GrepViewPlugin::showDialog()), is in kdevplatform/util/kdevplatform_shell_environment.sh => function dsearch!
OK, now I see how this happens: GrepOutputView() reads LastSettings KConfig entry, then creates a GrepDialog and starts historySearch() to "rerun the grep jobs with settings from the history" (why???). GrepDialog::historySearch() connects GrepDialog::checkProjectsOpened to IProjectController::projectOpened and invokes nextHistory(true) asynchronously, which calls GrepDialog::startSearch(). This invocation occurs when some nested event loop is entered - from Kasten::JobManager::executeJob() in the backtrace of the first comment in this bug. Apparently nextHistory() is inlined and thus missing from the backtraces. https://commits.kde.org/kdevelop/42eb6bb62c28923e5f6f4ff0cee3e8e6ee07bd2e has implemented this feature. I'll ask the author of that commit why the last search has to be rerun, as opposed to simply restoring the find-in-files history as requested by the linked bug reports, in a GitLab comment.
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/404
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/405
Git commit a2b3b77fea8147878ac727e7e5f8c4f3bbfce573 by Igor Kushnir. Committed on 25/11/2022 at 10:44. Pushed by igorkushnir into branch 'release/22.12'. Display GrepDialog results in the GrepOutputView that creates it GrepOutputView creates a hidden GrepDialog on start to restore search settings from history. GrepOutputView also creates a hidden GrepDialog when its Refresh action is triggered. In both cases the GrepOutputView becomes GrepDialog's parent, and thus will be valid when the dialog is ready to display results. Also in both cases the search results should not be displayed in a GrepOutputView from another area if that area becomes active before GrepDialog::startSearch() is invoked. And there is no need to raise the GrepOutputView in these cases either. GrepViewPlugin creates and usually shows GrepDialog for various reasons. The dialog is modeless, so the user can activate another area before starting a search in it. The results should be displayed in a GrepOutputView within the area active at the time of a search start. Therefore the old IUiController::findToolView()-based implementation remains for this case. Restoring search history in a session that contains zero projects (all closed), could cause a crash in a nested event loop inside UiController::loadAllAreas(), because UiController::findToolView() returns nullptr then and GrepDialog::startSearch() does not check the returned pointer. OktetaDocument can create such a nested event loop if a binary file is open in the session. FIXED-IN: 5.10.221200 M +11 -4 plugins/grepview/grepdialog.cpp M +6 -1 plugins/grepview/grepdialog.h M +2 -2 plugins/grepview/grepoutputview.cpp M +1 -1 plugins/grepview/grepviewplugin.cpp https://invent.kde.org/kdevelop/kdevelop/commit/a2b3b77fea8147878ac727e7e5f8c4f3bbfce573