Application: kdevelop (5.1.80-32-ge2a1d1f638) (Compiled from sources) Qt Version: 5.8.0 Frameworks Version: 5.38.0 Operating System: Linux 4.9.30-ck1-mainline-core2-rjvb x86_64 Distribution: Ubuntu 14.04.5 LTS -- Information about the crash: - What I was doing when the application crashed: I had been dragging the documentation toolview window to and from the dock to study how that behaves and how the toolbar button changes position when redocking the window on another side of the main window. Then, I closed the doc window by clicking on the toolbar window and quit KDevelop. This crash seems to indicate that the doc toolview goes through a complete initialisation at shutdown, which would explain why I sometimes see its window appear (in floating mode) when I exit KDevelop. This process in turn may explain why the toolview exhibitis random state restore behaviour (see #385556). I assume that DocumentationView::initialize() is being called here via the queued method invocation at the end of its ctor. I'll be testing a small modification: diff --git a/kdevplatform/documentation/documentationview.cpp b/kdevplatform/documentation/documentationview.cpp index 2c6cccf8bd742e69022be8ee002ea49246c93f03..c150804c44c8fd77ed9de408a26528daaf7c71eb 100644 --- a/kdevplatform/documentation/documentationview.cpp +++ b/kdevplatform/documentation/documentationview.cpp @@ -44,6 +44,10 @@ using namespace KDevelop; DocumentationView::DocumentationView(QWidget* parent, ProvidersModel* model) : QWidget(parent), mProvidersModel(model) { + if (ICore::self()->shuttingDown()) { + return; + } + setWindowIcon(QIcon::fromTheme(QStringLiteral("documentation"), windowIcon())); setWindowTitle(i18n("Documentation")); -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f5a2334d7c0 (LWP 15558))] Thread 6 (Thread 0x7f5a07616700 (LWP 15561)): #0 0x00007f5a1b989c5d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f5a11bc9b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007f5a11bcb64f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007f5a0a2a4549 in QXcbEventReader::run (this=0x7741b0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1345 #4 0x00007f5a1c558cf9 in QThreadPrivate::start (arg=0x7741b0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368 #5 0x00007f5a16bbc184 in start_thread (arg=0x7f5a07616700) at pthread_create.c:312 #6 0x00007f5a1b996ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 5 (Thread 0x7f59fc86e700 (LWP 15562)): #0 0x00007f5a1b98834d in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f5a12fd6940 in g_wakeup_acknowledge () from /opt/local/lib/libglib-2.0.so.0 #2 0x00007f5a12f7fac9 in g_main_context_check () from /opt/local/lib/libglib-2.0.so.0 #3 0x00007f5a12f80028 in g_main_context_iterate.isra () from /opt/local/lib/libglib-2.0.so.0 #4 0x00007f5a12f8018c in g_main_context_iteration () from /opt/local/lib/libglib-2.0.so.0 #5 0x00007f5a1c77659b in QEventDispatcherGlib::processEvents (this=0x7f59f80008c0, flags=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425 #6 0x00007f5a1c72217a in QEventLoop::exec (this=this@entry=0x7f59fc86dde0, flags=..., flags@entry=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212 #7 0x00007f5a1c5542ab in QThread::exec (this=this@entry=0x7f5a1e0c1460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread.cpp:507 #8 0x00007f5a1de51005 in QDBusConnectionManager::run (this=0x7f5a1e0c1460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:170 #9 0x00007f5a1c558cf9 in QThreadPrivate::start (arg=0x7f5a1e0c1460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368 #10 0x00007f5a16bbc184 in start_thread (arg=0x7f59fc86e700) at pthread_create.c:312 #11 0x00007f5a1b996ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 4 (Thread 0x7f59f4b3d700 (LWP 15563)): #0 0x00007ffd3b5a6b55 in ?? () #1 0x00007f59f00012d0 in ?? () #2 0x00000000f00018a0 in ?? () #3 0x00007f59f0002cd0 in ?? () #4 0x00007f59f0000990 in ?? () #5 0x000000007fffffff in ?? () #6 0x00007f5a1b9a54dd in __GI___clock_gettime (clock_id=clock_id@entry=1, tp=tp@entry=0x7f59f4b3cbc0) at ../sysdeps/unix/clock_gettime.c:115 #7 0x00007f5a1c775851 in qt_clock_gettime (ts=0x7f59f4b3cbc0, clock=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qelapsedtimer_unix.cpp:111 #8 do_gettime (frac=<synthetic pointer>, sec=<synthetic pointer>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qelapsedtimer_unix.cpp:166 #9 qt_gettime () at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qelapsedtimer_unix.cpp:175 #10 0x00007f5a1c7740b9 in QTimerInfoList::updateCurrentTime (this=0x261f20ca) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qtimerinfo_unix.cpp:91 #11 0x00007f5a1c775b45 in timerSourceCheckHelper (src=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:146 #12 idleTimerSourceCheck (source=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:223 #13 0x00007f5a12f7f94e in g_main_context_check () from /opt/local/lib/libglib-2.0.so.0 #14 0x00007f5a12f80028 in g_main_context_iterate.isra () from /opt/local/lib/libglib-2.0.so.0 #15 0x00007f5a12f8018c in g_main_context_iteration () from /opt/local/lib/libglib-2.0.so.0 #16 0x00007f5a1c77659b in QEventDispatcherGlib::processEvents (this=0x7f59f00008c0, flags=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425 #17 0x00007f5a1c72217a in QEventLoop::exec (this=this@entry=0x7f59f4b3cd90, flags=..., flags@entry=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212 #18 0x00007f5a1c5542ab in QThread::exec (this=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread.cpp:507 #19 0x00007f5a19b0317e in KDevelop::DUChainPrivate::CleanupThread::run (this=0x14de130) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/language/duchain/duchain.cpp:283 #20 0x00007f5a1c558cf9 in QThreadPrivate::start (arg=0x14de130) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368 #21 0x00007f5a16bbc184 in start_thread (arg=0x7f59f4b3d700) at pthread_create.c:312 #22 0x00007f5a1b996ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7f59ec109700 (LWP 15564)): #0 0x00007f5a1b989c5d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f5a12f80081 in g_main_context_iterate.isra () from /opt/local/lib/libglib-2.0.so.0 #2 0x00007f5a12f8018c in g_main_context_iteration () from /opt/local/lib/libglib-2.0.so.0 #3 0x00007f5a1c77659b in QEventDispatcherGlib::processEvents (this=0x7f59e40008c0, flags=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:425 #4 0x00007f5a1c72217a in QEventLoop::exec (this=this@entry=0x7f59ec108e10, flags=..., flags@entry=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212 #5 0x00007f5a1c5542ab in QThread::exec (this=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread.cpp:507 #6 0x00007f5a1c558cf9 in QThreadPrivate::start (arg=0x15549c0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368 #7 0x00007f5a16bbc184 in start_thread (arg=0x7f59ec109700) at pthread_create.c:312 #8 0x00007f5a1b996ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f59be7fc700 (LWP 15845)): #0 0x00007ffd3b5a6b55 in ?? () #1 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f5a2334d7c0 (LWP 15558)): [KCrash Handler] #6 0x0000000000000090 in ?? () #7 0x00007f5a1c755070 in QObject::connect (sender=sender@entry=0x3b64f30, signal=signal@entry=0x7f5a1d81c458 "2dataChanged(QModelIndex,QModelIndex)", receiver=receiver@entry=0x209a690, method=method@entry=0x7f5a1d81c428 "1_q_dataChanged(QModelIndex,QModelIndex)", type=type@entry=Qt::AutoConnection) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qobject.cpp:2649 #8 0x00007f5a1d5a4cb9 in QComboBox::setModel (this=0x209a690, model=0x3b64f30) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/widgets/qcombobox.cpp:2002 #9 0x00007f5a1984480e in DocumentationView::initialize (this=0xddfd00) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/documentation/documentationview.cpp:133 #10 0x00007f5a1c750121 in QObject::event (this=this@entry=0xddfd00, e=e@entry=0x151cf60) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qobject.cpp:1263 #11 0x00007f5a1d4e0453 in QWidget::event (this=0xddfd00, event=0x151cf60) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qwidget.cpp:9220 #12 0x00007f5a1d49ba5c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0xddfd00, e=0x151cf60) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qapplication.cpp:3745 #13 0x00007f5a1d4a2cd1 in QApplication::notify (this=0x7ffd3b435008, receiver=0xddfd00, e=0x151cf60) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/widgets/kernel/qapplication.cpp:3502 #14 0x00007f5a1c724018 in QCoreApplication::notifyInternal2 (receiver=0xddfd00, event=event@entry=0x151cf60) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:995 #15 0x00007f5a1c72667d in sendEvent (event=0x151cf60, receiver=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.h:231 #16 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x753480) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:1655 #17 0x00007f5a1c726ae8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:1509 #18 0x00007f5a1c776173 in postEventSourceDispatch (s=0x79c2f0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:276 #19 0x00007f5a12f7fe37 in g_main_context_dispatch () from /opt/local/lib/libglib-2.0.so.0 #20 0x00007f5a12f80108 in g_main_context_iterate.isra () from /opt/local/lib/libglib-2.0.so.0 #21 0x00007f5a12f8018c in g_main_context_iteration () from /opt/local/lib/libglib-2.0.so.0 #22 0x00007f5a1c77657f in QEventDispatcherGlib::processEvents (this=0x7fced0, flags=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:423 #23 0x00007f5a1c72217a in QEventLoop::exec (this=this@entry=0x7ffd3b434dd0, flags=..., flags@entry=...) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qeventloop.cpp:212 #24 0x00007f5a1c72a524 in QCoreApplication::exec () at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qcoreapplication.cpp:1268 #25 0x00000000004138e7 in main (argc=<optimized out>, argv=<optimized out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/app/main.cpp:919 Reported using DrKonqi
Git commit 4b4806d02ad099b5ef3062286a1dfdef21195ee4 by R.J.V. Bertin. Committed on 12/10/2017 at 19:02. Pushed by rjvbb into branch '5.2'. Don't set up DocumentationViews when shutting down In rare situations a DocumentationView can be created when shutting down, which can lead to race conditions and crashing. Prevent this by returning early from the class ctor when shutdown is in progress. In addition, prevent errors from QWidget::setTabOrder() by checking its input arguments. M +8 -1 kdevplatform/documentation/documentationview.cpp https://commits.kde.org/kdevelop/4b4806d02ad099b5ef3062286a1dfdef21195ee4
Note: I can't reproduce your problem. Tips to solve this correctly: Please put a breakpoint on "DocumentationView::DocumentationView(QWidget* parent, ProvidersModel* model)" and check where/when it is being called during shutdown. Post the backtrace, please.
Have you read the ticket and commit message? I cannot reproduce the issue at will either. It happens and *will* (always?) provoke a crash, but it does so seemingly randomly. If you want to run each and every KDevelop session under a debugger with a breakpoint set, be our guest (our as in everyone using the app). I don't have the resources for that. I don't agree with your analysis in this case. There's no point in setting up a DocumentationView when the application is exitting. Nothing done in that ctor is crucial unless you use the instance, and that's not going to happen. Alternatively, please provide a utility to print a backtrace in ICore or wherever appropriate if there isn't already. I'll use that to determine where the call comes from. (Yes, I could write such a utility class myself but this time I'm going to leave it to some of the powers that be who don't need drawn-out review procedures.) Oh, and you could have left the secondary fix in that commit.
(In reply to Kevin Funk from comment #2) > Note: I can't reproduce your problem. Could you please add something like this, at least? (Or use an ASSERT if you run with those in place.) --- a/kdevplatform/documentation/documentationview.cpp +++ b/kdevplatform/documentation/documentationview.cpp @@ -62,6 +62,10 @@ DocumentationView::DocumentationView(QWidget* parent, ProvidersModel* model) mCurrent = mHistory.end(); + if (ICore::self()->shuttingDown()) { + qFatal("DocumentationView created during shutdown"); + } + setFocusProxy(mIdentifiers); QMetaObject::invokeMethod(this, "initialize", Qt::QueuedConnection);
Created attachment 108328 [details] debugging patch I'll be running with this myself (in hope it's safe to call KMessageBox when this issue occurs).
> Have you read the ticket and commit message? I cannot reproduce the issue at will either. It happens and *will* (always?) provoke a crash, but it does so seemingly randomly. Yes. It told me you haven't fully understood the problem and you're adding hacks which inevitably may cause other crashes (i.e. when DocumentationView is being destructed again, trying to cleanup resources which were never initialized properly). > If you want to run each and every KDevelop session under a debugger with a breakpoint set, be our guest (our as in everyone using the app). I don't have the resources for that. What's the problem with running it under GDB? Not having the resources for that is not an excuse if you want to actively develop and file patches for a project. > I don't agree with your analysis in this case. There's no point in setting up a DocumentationView when the application is exitting. I don't or didn't concur with that. > Nothing done in that ctor is crucial unless you use the instance, and that's not going to happen. And you know that it isn't used based on...? How can you know it's not being used if you don't know where/when the class is being instantiated? > Alternatively, please provide a utility to print a backtrace in ICore or wherever appropriate if there isn't already. I'll use that to determine where the call comes from. https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for "backtrace" -- you can enable them for e.g. warnings exclusively. > (Yes, I could write such a utility class myself but this time I'm going to leave it to some of the powers that be who don't need drawn-out review procedures.) I see what you're hinting at. Please note that "drawn-out" review procedures are only necessary in "special cases". It's definitely not happing for the majority of incoming reviews for KDevelop. The key point in not ending up with lengthy discussions in reviews is a) having a good understanding of the problem at hand before even trying put up patches for review, b) focusing on one issue at a time during discussions, c) posting a patch where you have good confidence that it is the right fix to begin with and not a series of obvious work-arounds. > Oh, and you could have left the secondary fix in that commit. Yes, or the original author could have at least committed that hunk separately, with a proper commit message explaining what this change does.
(In reply to Kevin Funk from comment #6) > Yes. It told me you haven't fully understood the problem I've understood (accepted) that the complexity of the plugin/toolview architecture is in large part beyond me, just like you yourself have accepted that the itemrepository issue is beyond you. I may be wrong about that, but I've been looking on and off at the seemingly random aspect of the documentation toolview for probably more than a year now (and I've been putting up with it since v4.x). And so what if we figure out where the creation comes from. We put the "don't do this when shutting down" check there? > hacks which inevitably may cause other crashes (i.e. when DocumentationView > is being destructed again, trying to cleanup resources which were never > initialized properly). Seriously? There's only a default dtor, which doesn't know about anything allocated dynamically through the ctor after the early return. > > Nothing done in that ctor is crucial unless you use the instance, and that's not going to happen. > > And you know that it isn't used based on...? How can you know it's not being > used if you don't know where/when the class is being instantiated? Ok, can you explain how a toolview could use the stuff it sets up for letting the user interact with it after the program exit, if it cannot stop that process? I'll give it to you that the return was maybe a bit too early and should rather exclude only the invocation of the initialisation method. In practice I've seen the warning print a few times without any further crashing. I wouldn't have committed this without testing. > https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for > "backtrace" -- you can enable them for e.g. warnings exclusively. That might be useful for critical messages, but still, Linux only apparently, and I don't think you have this kind of control in the code just before a specific log output. Or is there a way to do that? > Please note that "drawn-out" review procedures are only necessary in > "special cases". They tend to get drawn out for other reasons too, ultimately leading to a core dev "remote controlling" what boils down to one of his clones to write a piece of code. It's just more efficient to skip the remote clone bit in those cases. > Yes, or the original author could have at least committed that hunk > separately, with a proper commit message explaining what this change does. I am the original author ... can I take that as a green light to commit it? (I kind of expected that Friedrich would commit this, as it's a fix for something he introduced.)
> What's the problem with running it under GDB? Nothing, except that it takes minutes just to get the app to start (lldb is a bit faster on my Mac) and it takes up gobs of additional RAM. That's OK when I need actual debugger functionality like stepping through code or examining variables. It's not feasible as a general runtime environment just to obtain a backtrace. Esp. when you're rebuilding and restarting the app over an over again to test tweaks like the standalone dockwidget (= how I spent much of my yesterday). My main reason for contributing is that I use the application (which is what I try to do between patch revision procedures), and that it's a priori more efficient to get my modifications upstreamed instead of maintaining a fork that will inevitably become too much to handle.
> > https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for > "backtrace" -- you can enable them for e.g. warnings exclusively. It turns out that seting QT_MESSAGE_PATTERN from the code has the intended effect, but the %{backtrace} feature is only available on glib-based platforms. It also doesn't provide very useful backtraces; no demangling, no filenames let alone line numbers. A very simple test (qInfo() called from a function loggertest() called from main() in an application called qlogging prints this: ?qlogging?|?qlogging?|__libc_start_main|?qlogging? (even when built with -O0 -g)
Thank you for the crash report. As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!