In commit 86b7aaf408383aad4f27910c9259494e7d0e1e51 of plasma-workspace a notification is removed after an action is invoked. Despite the timer, this still leads to crashes when I invoke a notification. dolphin & kill -6 `pidof dolphin` now click "Report bug" in the notification → Plasma will likely crash I would have wished this had gone through Phabricator... Also, Gnome notification spec knows a "resident" notification which stays there even after you triggered an action, so unconditionally doing this here is wrong imho. We already close the notification popup anyway.
I agree this shouldn't have been done this way and that this should at least be run by the notifications maintainer, which is Kai.
I cannot get plasma to crash this way, can you re-test with the changes we did yesterday?
Still crashing: Thread 1 (Thread 0x7fe380cb08c0 (LWP 4038)): [KCrash Handler] #6 0x00007fe37f1ac3eb in Plasma::DataEngine::removeSource(QString const&) () from /usr/lib/x86_64-linux-gnu/libKF5Plasma.so.5 #7 0x00007fe2ae3655f8 in NotificationAction::start()::{lambda()#2}::operator()() const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_notifications.so #8 0x00007fe2ae366e2b in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, NotificationAction::start()::{lambda()#2}>::call({lambda()#2}&, void**) () from /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_notifications.so #9 0x00007fe2ae366dfd in void QtPrivate::Functor<NotificationAction::start()::{lambda()#2}, 0>::call<QtPrivate::List<>, void>({lambda()#2}&, void*, {lambda()#2}&*) () from /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_notifications.so #10 0x00007fe2ae366dc2 in QtPrivate::QFunctorSlotObject<NotificationAction::start()::{lambda()#2}, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) () from /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_notifications.so #11 0x00007fe37be8f546 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x00007fe37be83d53 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x00007fe37c736ecc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #14 0x00007fe37c73e8c6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x00007fe37be580c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x00007fe37beaa68e in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No crash when i ran dolphin & kill -6 'pidof dolphin' It complains about "bash: kill: pidof dolphin: arguments must be process or job IDs" I launched a dolphin instance and ran dolphin & kill -6 'pidof dolphin' again no crash. Using the PID of dolphin still does not trigger the crash. Now running it without '' it does every-time. dolphin & kill -6 pidof [pid of dolphin here]
You have to use ` ` quotes, not ' '. `command` in bash actually executes the command in between those quotes.
(In reply to Martin Klapetek from comment #5) > You have to use ` ` quotes, not ' '. `command` in bash actually executes the > command in between those quotes. Ups my bad. Running kill -6 `pidof dolphin` does not trigger the crash on neon, unless a dolphin instance is running beforehand. Application: Dolphin (dolphin), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f90ff5a78c0 (LWP 3172))] Thread 5 (Thread 0x7f90d56b6700 (LWP 3177)): #0 0x00007f90fefa1b5d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f90f3b9938c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f90f3b9949c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f90f9cce75b in QEventDispatcherGlib::processEvents (this=0x7f90d00008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x00007f90f9c790ba in QEventLoop::exec (this=this@entry=0x7f90d56b5d00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x00007f90f9aa8f64 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:507 #6 0x00007f90f9aadb48 in QThreadPrivate::start (arg=0x24600d0) at thread/qthread_unix.cpp:368 #7 0x00007f90f5eee6ba in start_thread (arg=0x7f90d56b6700) at pthread_create.c:333 #8 0x00007f90fefad82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f90e12a6700 (LWP 3176)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x00007f90e335ae44 in ?? () from /usr/lib/nvidia-378/libGLX_nvidia.so.0 #2 0x00007f90e2072394 in ?? () from /usr/lib/nvidia-378/libnvidia-glcore.so.378.13 #3 0x00007f90e335a12c in ?? () from /usr/lib/nvidia-378/libGLX_nvidia.so.0 #4 0x00007f90f5eee6ba in start_thread (arg=0x7f90e12a6700) at pthread_create.c:333 #5 0x00007f90fefad82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f90e88a6700 (LWP 3174)): #0 0x00007f90f5ef52f8 in __GI___pthread_getspecific (key=5) at pthread_getspecific.c:60 #1 0x00007f90f3bc0060 in g_thread_self () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f90f3b9948d in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f90f9cce75b in QEventDispatcherGlib::processEvents (this=0x7f90dc0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x00007f90f9c790ba in QEventLoop::exec (this=this@entry=0x7f90e88a5cd0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x00007f90f9aa8f64 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:507 #6 0x00007f90ff68c735 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #7 0x00007f90f9aadb48 in QThreadPrivate::start (arg=0x7f90ff700d60) at thread/qthread_unix.cpp:368 #8 0x00007f90f5eee6ba in start_thread (arg=0x7f90e88a6700) at pthread_create.c:333 #9 0x00007f90fefad82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7f90ea6d6700 (LWP 3173)): #0 0x00007f90fefa1b5d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f90f2e80c62 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007f90f2e828d7 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007f90ed2a2d79 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #4 0x00007f90f9aadb48 in QThreadPrivate::start (arg=0x1cc5ff0) at thread/qthread_unix.cpp:368 #5 0x00007f90f5eee6ba in start_thread (arg=0x7f90ea6d6700) at pthread_create.c:333 #6 0x00007f90fefad82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f90ff5a78c0 (LWP 3172)): [KCrash Handler] #6 0x00007f90fefa1b5d in poll () at ../sysdeps/unix/syscall-template.S:84 #7 0x00007f90f3b9938c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x00007f90f3b9949c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x00007f90f9cce73f in QEventDispatcherGlib::processEvents (this=0x1cf5800, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #10 0x00007f90f9c790ba in QEventLoop::exec (this=this@entry=0x7ffc6a8735d0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #11 0x00007f90f9c816cc in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1261 #12 0x00007f90ff2d42a9 in kdemain (argc=1, argv=<optimized out>) at /workspace/build/src/main.cpp:150 #13 0x00007f90feec7830 in __libc_start_main (main=0x4006b0 <main(int, char**)>, argc=1, argv=0x7ffc6a873898, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc6a873888) at ../csu/libc-start.c:291 #14 0x00000000004006e9 in _start ()
Your backtrace has nothing to do with this crash. I am refering to plasmashell crashing, not Dolphin. If you kill -6 dolphin, of course it will crash because that's what you told it to do. I just used this as an example as provoking a DrKonqi is an easy way to get a notification with buttons in it ;) clicking one of the buttons in the "Dolphin closed unexpectedly" notification will crash plasmashell usually. This is what this bug is about. Sorry for the confusion.
I think it would make sense to just revert 86b7aaf408383aad4f27910c9259494e7d0e1e51, that would keep the notification in history, which i think would also make sense from an interaction pov?
Fine with me but I didn't just want to go ahead as there might be a better solution?
(In reply to Kai Uwe Broulik from comment #9) > Fine with me but I didn't just want to go ahead as there might be a better > solution? that indiscriminately removing the notification from history wasn't really tought trough and even design-wise i find it questionable, i still think it was a wrong call and should be reverted
Git commit 40d42d55e3ab5a10ccec45dac6b0196f36a2a587 by Marco Martin. Committed on 10/03/2017 at 15:49. Pushed by mart into branch 'master'. Revert "After a notification action is triggered, remove the action" This reverts commit 86b7aaf408383aad4f27910c9259494e7d0e1e51. this causes a crash at the action triggering and removing the action from history upon action triggering is debatable from an ui pov reviewed-by: kbroulik M +1 -5 dataengines/notifications/notificationaction.cpp https://commits.kde.org/plasma-workspace/40d42d55e3ab5a10ccec45dac6b0196f36a2a587