Summary: | Crash in QAccessible::queryAccessibleInterface | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-ktexteditor | Reporter: | Zamundaaa <xaver.hugl> |
Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | a.samirh78, admin, christoph, debian, doc.evans, gmrandazzo, igorkuo, mail, mirovski36, piotr.mierzwinski, pruefer, robert, thijs.withaar, waqar.17a |
Priority: | VHI | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Zamundaaa
2021-12-31 13:33:41 UTC
*** Bug 451041 has been marked as a duplicate of this bug. *** Hm, since you're not seeing it, it is of course possible it's specific to KDevelop. But in this trace, the KDevelop stacktrace looks innocent enough to me... the git plugin detected changes in this document, so it is being reloaded, and from the reload on everything is in KTextEditor only. Maybe some special condition is needed to trigger this, I could e.g. imagine something like "a document is being reloaded for which the view has never been visible before"? Unfortunately I have absolute zero knowledge about QAccessible :/ Has it ever crashed in X? Maybe this is something specific to wayland, and it could be that kate users are just lucky till now The other bug https://bugs.kde.org/show_bug.cgi?id=451041 says X11... I've seen it crashing with a similar backtrace on X11 myself as well. Did some digging, but didn't get anywhere. Maybe the accessibleInterface pointer inside updateAccessibility() is invalid which leads to a crash. When we reload the doc, the views, if any are valid before and after regardless of whether they became visible or not. A quick workaround fix would be to allow the user to disable/enable accessibility. This would avoid the crash. I noticed this in the backtrace: #3 0x00007f4bde872db7 in KateViewInternal::cursorMoved() (this=0x563c189c63c0) at /home/xaver/kde/src/ktexteditor/src/view/kateviewinternal.cpp:4114 ev = <incomplete type> "incomplete type" is a bit weird; looking at ktexteditor: void KateViewInternal::cursorMoved() { view()->updateRangesIn(KTextEditor::Attribute::ActivateCaretIn); #ifndef QT_NO_ACCESSIBILITY if (QAccessible::isActive()) { QAccessibleTextCursorEvent ev(this, static_cast<KateViewAccessible *>(QAccessible::queryAccessibleInterface(this))->positionFromCursor(this, m_cursor)); QAccessible::updateAccessibility(&ev); } #endif } QAccessible::queryAccessibleInterface() returns a QAccessibleInterface*, so we'd have to use QAccessibleInterface::textInterface() to get a QAccessibleTextInterface*; not sure if this makes a difference but I'd try: @@ -4597,7 +4597,8 @@ void KateViewInternal::cursorMoved() #ifndef QT_NO_ACCESSIBILITY if (QAccessible::isActive()) { - QAccessibleTextCursorEvent ev(this, static_cast<KateViewAccessible *>(QAccessible::queryAccessibleInterface(this))->positionFromCursor(this, m_cursor)); + KateViewAccessible *iface = static_cast<KateViewAccessible *>(QAccessible::queryAccessibleInterface(this)->textInterface()); + QAccessibleTextCursorEvent ev(this, iface->positionFromCursor(this, m_cursor)); QAccessible::updateAccessibility(&ev); } #endif (If it works, feel free to use it in a MR). I can't reproduce this myself. I fail to see how the change can work, given in all other locations we don't use the ->textInterface() call either, or are they all wrong? I was wrong, somehow the compiler casts it to the appropriate type; I was confused by the <incomplete type> in the backtrace, but that could be gdb confused too by too many layers of inheritance/casts. Still keeps crashing "randomly". Few minutes ago just after pressing Alt+TAB to get into KDevelop followed by pressing key "Key_Down" (immediatelly) in order to see lower lines in the current editor tab with some python code. It is possible that the Ctrl key has been pressed too at the same time (HP laptop with some bios troubles in linux - it generates Ctrl key press randomly, especially under heavy load - not spotted in MS Windows when analysed by our technicians). It has been the first crash in QAccessibleEvent related to a key press. Usually, it crashes just after LMB on an editor tab or inside the editor window, but I think, always just after applications switch. Updated Archlinux (5.98.0, 22.08.1), KDevelop with VI mode and with the kdev-python plugin from AUR. Normal X-server configuration with plasma, no any wayland. Application: KDevelop (kdevelop), signal: Segmentation fault [KCrash Handler] #4 0x00007f169e715f90 in QAccessibleObject::object() const () at /usr/lib/libQt5Gui.so.5 #5 0x00007f169f1c00de in QAccessibleWidget::isValid() const () at /usr/lib/libQt5Widgets.so.5 #6 0x00007f169e71f0fd in QAccessibleEvent::accessibleInterface() const () at /usr/lib/libQt5Gui.so.5 #7 0x00007f169e71acb5 in QAccessible::updateAccessibility(QAccessibleEvent*) () at /usr/lib/libQt5Gui.so.5 #8 0x00007f169bde0614 in KateViewInternal::cursorMoved() () at /usr/lib/libKF5TextEditor.so.5 #9 0x00007f169bdd6bff in KateViewInternal::updateCursor(KTextEditor::Cursor, bool, bool, bool) () at /usr/lib/libKF5TextEditor.so.5 #10 0x00007f169be50cdd in KateVi::NormalViMode::handleKeypress(QKeyEvent const*) () at /usr/lib/libKF5TextEditor.so.5 #11 0x00007f169be6169c in KateVi::InputModeManager::handleKeypress(QKeyEvent const*) () at /usr/lib/libKF5TextEditor.so.5 #12 0x00007f169be3e88a in KateViInputMode::keyPress(QKeyEvent*) () at /usr/lib/libKF5TextEditor.so.5 #13 0x00007f169be3b8f7 in KateViInputMode::stealKey(QKeyEvent*) () at /usr/lib/libKF5TextEditor.so.5 #14 0x00007f169bde2875 in KateViewInternal::eventFilter(QObject*, QEvent*) () at /usr/lib/libKF5TextEditor.so.5 #15 0x00007f169e28c7f2 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #16 0x00007f169ef78b0c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #17 0x00007f169ef7ddf8 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #18 0x00007f169e28cb88 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #19 0x00007f169efcf18b in () at /usr/lib/libQt5Widgets.so.5 #20 0x00007f169ef78b1c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #21 0x00007f169e28cb88 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #22 0x00007f169e73fb50 in QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*) () at /usr/lib/libQt5Gui.so.5 #23 0x00007f169e720dfe in bool QWindowSystemInterfacePrivate::handleWindowSystemEvent<QWindowSystemInterface::SynchronousDelivery>(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /usr/lib/libQt5Gui.so.5 #24 0x00007f169e72a0e6 in QWindowSystemInterface::handleShortcutEvent(QWindow*, unsigned long, int, QFlags<Qt::KeyboardModifier>, unsigned int, unsigned int, unsigned int, QString const&, bool, unsigned short) () at /usr/lib/libQt5Gui.so.5 #25 0x00007f169e73faf2 in QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*) () at /usr/lib/libQt5Gui.so.5 #26 0x00007f169e728985 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Gui.so.5 #27 0x00007f167ff2f6c0 in () at /usr/lib/libQt5XcbQpa.so.5 #28 0x00007f169a1e281b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #29 0x00007f169a238ec9 in () at /usr/lib/libglib-2.0.so.0 #30 0x00007f169a1e10d2 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #31 0x00007f169e2d750c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #32 0x00007f169e28532c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #33 0x00007f169e28fe59 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #34 0x0000558bfb28cba9 in () #35 0x00007f169da3c290 in () at /usr/lib/libc.so.6 #36 0x00007f169da3c34a in __libc_start_main () at /usr/lib/libc.so.6 #37 0x0000558bfb28d715 in () [Inferior 1 (process 3769) detached] *** Bug 462455 has been marked as a duplicate of this bug. *** *** Bug 446487 has been marked as a duplicate of this bug. *** *** Bug 448885 has been marked as a duplicate of this bug. *** *** Bug 449294 has been marked as a duplicate of this bug. *** *** Bug 453684 has been marked as a duplicate of this bug. *** *** Bug 453773 has been marked as a duplicate of this bug. *** *** Bug 472891 has been marked as a duplicate of this bug. *** Since we haven't gotten even a single bugreport from Kate users I am inclined to believe that this might be a bug in KDevelop *** Bug 473250 has been marked as a duplicate of this bug. *** Just to confirm that this isn't associated with Wayland. I reported bug https://bugs.kde.org/show_bug.cgi?id=473251 which is perhaps the same bug (although I'm not absolutely certain about that) and I don't use Wayland at all. In fact here it's always X-over-ssh. In case it helps, here is part of my most recent post on bug 473251: ---- 2. The crashes occur at the rate of about two per hour... I can get work done, but it's certainly annoying to be interrupted by crashes so frequently. 3. I have not found a particular sequence of actions that is guaranteed to reproduce the crash. 4. I *think* that crashes happen only when I've actively interacted with the editor window: either I'm in the middle of typing, or at the very least, I've just clicked somewhere in the window. 5. FYI, the project I'm working on is: https://github.com/N7DR/drlog. ---- Since installing debian bookworm on the computer in question, I have never seen any crash except when using kdevelop (i.e., not when using Kate or any other KDE program). When I reported this bug (as https://bugs.kde.org/show_bug.cgi?id=472891) I was using the nouveau driver on the X server. Using that driver, the crashes were frequent. Last week I switched to the modesetting driver (details in this thread: https://lists.debian.org/debian-user/2023/09/msg00218.html) on the machine on which the X server resides. Since then, this crash has not occurred, despite considerable use of kdevelop. No other relevant changes that I know of were made. (In reply to doc.evans from comment #21) > When I reported this bug (as https://bugs.kde.org/show_bug.cgi?id=472891) I > was using the nouveau driver on the X server. Using that driver, the crashes > were frequent. > > Last week I switched to the modesetting driver (details in this thread: > https://lists.debian.org/debian-user/2023/09/msg00218.html) on the machine > on which the X server resides. Since then, this crash has not occurred, > despite considerable use of kdevelop. > > No other relevant changes that I know of were made. I spoke too soon. I am still seeing crashes. I get the distinct impression that they are less frequent, but perhaps that's just wishful thinking. It was certainly true for a while after changing drivers, but I could believe that that was just random happenstance. *** Bug 475766 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/617 Git commit a64125ae585c96ee16081fc75d525624311001cc by Waqar Ahmed. Committed on 19/10/2023 at 18:31. Pushed by cullmann into branch 'master'. Allow enabling/disabling accessibility On Manjaro KDE (and possibly others) it seems that accessibility is always enabled for some reason. Lately it has been causing a lot of crashes in KDevelop and in general it is really bad for performance especially if you are doing something that results in a large number of edits at once M +17 -0 src/dialogs/editconfigwidget.ui M +3 -0 src/dialogs/katedialogs.cpp M +1 -0 src/utils/kateconfig.cpp M +1 -0 src/utils/kateconfig.h M +2 -0 src/view/kateview.cpp M +1 -0 src/view/kateview.h M +3 -3 src/view/kateviewinternal.cpp https://invent.kde.org/frameworks/ktexteditor/-/commit/a64125ae585c96ee16081fc75d525624311001cc (In reply to Waqar Ahmed from comment #25) > > Allow enabling/disabling accessibility > > On Manjaro KDE (and possibly others) it seems that accessibility is > always enabled for some reason. Lately it has been causing a lot of > crashes in KDevelop and in general it is really bad for performance So I am quite puzzled by the above. I obviously have KDE installed, otherwise I could not be using kdevelop. But I'm not actually running KDE as a desktop environment on either of the machines here that exhibit the problem. So is there some KDE-related config file somewhere that I should edit in order to be sure that accessibility support is turned off when I run kdevelop? (FWIW, on one machine I simply ssh into the machine and run kdevelop over the network, so there is no desktop environment at all; on the other machine I am using Trinity as the desktop environment.) *** Bug 475924 has been marked as a duplicate of this bug. *** (In reply to doc.evans from comment #26) > So I am quite puzzled by the above. I obviously have KDE installed, > otherwise I could not be using kdevelop. But I'm not actually running KDE as > a desktop environment on either of the machines here that exhibit the > problem. So is there some KDE-related config file somewhere that I should > edit in order to be sure that accessibility support is turned off when I run > kdevelop? The commit adds at option to turn accessibility off into the Editor=>Editing=>General page of the Configure KDevelop dialog. However the commit wasn't cherry picked into the kf5 branch. So it will become available in KDevelop only once it is ported to KF6. If someone can confirm that patching a KF5 version of KTextEditor with the commit and turning accessibility off eliminates this crash, then maybe we could cherry-pick it into the kf5 branch of KTextEditor. One can turn it off in master and for any more changes we would need a way to reproduce this. (In reply to Igor Kushnir from comment #28) > (In reply to doc.evans from comment #26) > > So I am quite puzzled by the above. I obviously have KDE installed, > > otherwise I could not be using kdevelop. But I'm not actually running KDE as > > a desktop environment on either of the machines here that exhibit the > > problem. So is there some KDE-related config file somewhere that I should > > edit in order to be sure that accessibility support is turned off when I run > > kdevelop? > The commit adds at option to turn accessibility off into the > Editor=>Editing=>General page of the Configure KDevelop dialog. However the > commit wasn't cherry picked into the kf5 branch. So it will become available > in KDevelop only once it is ported to KF6. If someone can confirm that > patching a KF5 version of KTextEditor with the commit and turning > accessibility off eliminates this crash, then maybe we could cherry-pick it > into the kf5 branch of KTextEditor. I have no way to test anything... just an ordinary user... but I got hit with this five times in less than an hour a couple of days ago when I was trying to tidy up some code, so am seriously thinking of going back to codelite (which certainly has problems of its own, which is why I left it in favour of kdevelop, but at least it doesn't crash), just because this bug is so frustrating and keeps getting in the way of the task at hand -- it feels like driving a car that stalls every few miles :-( -- yes, you can get the job done, but you waste an awful lot of time trying to get the car restarted (or recovering from the kdevelop crash). Hi, just to be sure: That happens for Kate, too? (In reply to Christoph Cullmann from comment #31) > Hi, just to be sure: That happens for Kate, too? If that question is intended for me, the answer is that, per comment #20, the only program in which I've experienced a crash is kdevelop. (In reply to doc.evans from comment #32) > (In reply to Christoph Cullmann from comment #31) > > Hi, just to be sure: That happens for Kate, too? > > If that question is intended for me, the answer is that, per comment #20, > the only program in which I've experienced a crash is kdevelop. Yes, thanks. If that only is triggered there, I am not sure that is really a KTextEditor issue. (In reply to Christoph Cullmann from comment #33) > Yes, thanks. If that only is triggered there, I am not sure that is really a > KTextEditor issue. I have no idea where the issue lies. Since I'm just an ordinary person trying to get some work done on my debian stable systems, all I can do really is report the bug and send stack traces, which is what I've done. My original report is https://bugs.kde.org/show_bug.cgi?id=473251. I think that I'll just go back to using codeview; I'm spending too long waiting waiting for kdevelop to recover after each crash; it's just too frustrating to try to use something that's so unstable :-( The main project that I'm working on, https://github.com/N7DR/drlog, is big enough that even just starting kdevelop with that project takes more than a minute on my development machine. Waiting all that time after each kdevelop crash really is getting to be just too frustrating :-( Since my KDE Bug reporting tool still hangs on final bug-submission (no way of getting entered text back), i have to repeat the bug-reporting without a back-trace attached. Also i can not find where the core-dump has been saved locally. The application (KDevelop) crashed with a Segmentation Fault (core-dumped), this is an indicator that some sort of null-pointer, double-free or similar has happened (in kernel). Since the bug occurred repeatedly on my systems multiple times, regardless of Linux-System, Windows Manager (X11 and Wayland), Graphics Driver (Intel, Nuveau or compiled NVIDIA drivers), i assume the cause is to find somewhere in "Mouse / Keyboard" interface handling of involved interfaces (Kernel / QT / KDE Base / Kate), maybe in combination with source-code highlighting update / triggering (indicator in first comment / back-trace: "KDevelop::TextDocument::reload()" or "QAccessibleEvent::accessibleInterface()"). Also the crash happened multiple times after my mouse-cursor got laggy in Firefox-browser (maybe interrupt handling / network interface card / malware). The case the same crash occurred on internet-less setup multiple times excludes the malware suspect (but do not underestimate malware creators). All back-traces include "QAccessibleEvent::accessibleInterface()" and "QAccessible::updateAccessibility(QAccessibleEvent*) () and KateViewInternal::cursorMoved()". Additionally i can report that i clicked the mouse accidentally multiple times quite fast, this could be an indicator that somewhere a queue processing (threaded?) contains too much or too less pointers or pointers to already deleted memory (maybe time dependent too). As already mentioned, the occurrence is Linux independent, but to complete information: Operating System: Devuan GNU/Linux 5 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-33-amd64 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-2520M CPU @ 2.50GHz Memory: 7.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 3000 Manufacturer: LENOVO Product Name: 4236N3G System Version: ThinkPad T420 Hopefully i could help finding the bug. (In reply to Claus Prüfer from comment #35) > KDE Frameworks Version: 5.103.0 > Qt Version: 5.15.8 KTextEditor 5.x and KDevelop 5.x are no longer supported and no new 5.x releases are planned. If this crash occurs in KDevelop 6.x, a workaround is to disable the "Enable accessibility notifications" option on the Editor->Editing tab of the Configure KDevelop dialog. I am using Devuan current (also Debian current) and it does not provide 6.x KDevelop versions. Also a bug should be fixed, or do you want to live along with a non-fixed bug over years (Windows like)? This is no good reputation. I could live with a statement like: "The bug is located and fixed in 6.x version", but not with "A workaround exists to disable". Now i get this backtrace on closing KDevelop. Application: KDevelop (kdevelop), signal: Aborted [KCrash Handler] #4 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #5 0x00007f2bdbea9f4f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #6 0x00007f2bdbe5afb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #7 0x00007f2bdbe45472 in __GI_abort () at ./stdlib/abort.c:79 #8 0x00007f2bdbe9e42f in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f2bdbfb8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:156 #9 0x00007f2bdbeb386a in malloc_printerr (str=str@entry=0x7f2bdbfbb0c8 "free(): invalid next size (fast)") at ./malloc/malloc.c:5660 #10 0x00007f2bdbeb56da in _int_free (av=0x7f2bdbff1c60 <main_arena>, p=0x55825018c800, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4518 #11 0x00007f2bdbeb7f4f in __GI___libc_free (mem=<optimized out>) at ./malloc/malloc.c:3385 #12 0x00007f2bdc2e8f8f in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x00007f2bdc2e22df in QObject::destroyed(QObject*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x00007f2bdcfa0a93 in QWidget::~QWidget() () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x00007f2bd9bfbf39 in KateViewInternal::~KateViewInternal() () from /usr/lib/x86_64-linux-gnu/libKF5TextEditor.so.5 #16 0x00007f2bd9bdd82b in KTextEditor::ViewPrivate::~ViewPrivate() () from /usr/lib/x86_64-linux-gnu/libKF5TextEditor.so.5 #17 0x00007f2bd9bddc89 in KTextEditor::ViewPrivate::~ViewPrivate() () from /usr/lib/x86_64-linux-gnu/libKF5TextEditor.so.5 #18 0x00007f2bd9fde3bf in Sublime::View::~View() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformSublime.so.510 #19 0x00007f2bdddc9dd9 in KDevelop::TextView::~TextView() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #20 0x00007f2bd9fd05c1 in Sublime::Document::closeViews() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformSublime.so.510 #21 0x00007f2bdddc91d2 in KDevelop::PartDocument::close(KDevelop::IDocument::DocumentSaveMode) () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #22 0x00007f2bdddd4ba2 in KDevelop::DocumentController::cleanup() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #23 0x00007f2bdddaab5e in KDevelop::Core::cleanup() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #24 0x00007f2bdddaae5a in KDevelop::Core::shutdown() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #25 0x00007f2bddd8d21b in KDevelop::MainWindow::~MainWindow() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #26 0x00007f2bddd8d279 in KDevelop::MainWindow::~MainWindow() () from /usr/lib/x86_64-linux-gnu/libKDevPlatformShell.so.510 #27 0x00007f2bdc2dd4ff in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #28 0x00007f2bd9efb307 in KXmlGuiWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5 #29 0x00007f2bdcf62fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #30 0x00007f2bdc2b1738 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #31 0x00007f2bdc2b46c1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #32 0x00007f2bdc30a193 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #33 0x00007f2bd7fd47a9 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #34 0x00007f2bd7fd4a38 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #35 0x00007f2bd7fd4acc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #36 0x00007f2bdc309876 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #37 0x00007f2bdc2b01bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #38 0x00007f2bdc2b8316 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #39 0x00005582342c1699 in ?? () #40 0x00007f2bdbe4624a in __libc_start_call_main (main=main@entry=0x5582342bccc0, argc=argc@entry=1, argv=argv@entry=0x7ffcf56a8668) at ../sysdeps/nptl/libc_start_call_main.h:58 #41 0x00007f2bdbe46305 in __libc_start_main_impl (main=0x5582342bccc0, argc=1, argv=0x7ffcf56a8668, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcf56a8658) at ../csu/libc-start.c:360 #42 0x00005582342c2281 in ?? () [Inferior 1 (process 6468) detached] (In reply to Claus Prüfer from comment #37) > I am using Devuan current (also Debian current) and it does not provide 6.x > KDevelop versions. > Also a bug should be fixed, or do you want to live along with a non-fixed > bug over years (Windows like)? > This is no good reputation. I could live with a statement like: "The bug is > located and fixed in 6.x version", but not with "A workaround exists to > disable". I don't know whether the bug is present in KDevelop 6.x. I could never reproduce it even in 5.x. (In reply to Claus Prüfer from comment #38) > Now i get this backtrace on closing KDevelop. > #16 0x00007f2bd9bdd82b in KTextEditor::ViewPrivate::~ViewPrivate() () from > /usr/lib/x86_64-linux-gnu/libKF5TextEditor.so.5 > #17 0x00007f2bd9bddc89 in KTextEditor::ViewPrivate::~ViewPrivate() () from > /usr/lib/x86_64-linux-gnu/libKF5TextEditor.so.5 > #18 0x00007f2bd9fde3bf in Sublime::View::~View() () from > /usr/lib/x86_64-linux-gnu/libKDevPlatformSublime.so.510 > #19 0x00007f2bdddc9dd9 in KDevelop::TextView::~TextView() () from This backtrace looks similar to those reported in Bug 439963 and Bug 480162. If you reproduce and fix either crash in KDevelop 6, please create a merge request. *** Bug 503178 has been marked as a duplicate of this bug. *** We tried to reproduce the accessibility crashes and we fixed some things for 6.x, but I don't think there was ever a proper way to reproduce all reported crashes to be sure we got all. Yes, i know it is not easy to detect this kind of bug. I try to demystify it since years, but still no clue. What i did currently: i switched to XFCE window manager (X11) with QT integration and disabled "all" plugins except "KDE File Manager Integration" and "Python Support" ("kdevelop-python" Debian package also installed). Also disabled Background Parser: problem gone. But: it crashed right after pressing "apply" button after disabling the plugins (and no back-trace was shown). I also switched to software rendering in one of my development virtual machines: problem seems also to be resolved. Someone also mentioned that it could be graphics related (opengl / driver?) also a common Linux problem. Additionally i realized that often when i am working with multiple open files (in multiple splitted areas) that the background parsers (pointers) get puzzled and on click the highlighted areas do not match with the program code anymore. This also could be a null-pointer / de-referencing or similar problem. I will try to update / compile a newer KDE / QT version and investigate further. |