[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 --- Comment #7 from Matt Fagnani --- /usr/lib/systemd/user/plasma-plasmashell.service had TimeoutSec=40sec. So when drkonqi was still creating the trace of plasmashell 40 s after plasmashell crashed, systemd aborted plasma-plasmashell.service's processes plasmashell, drkonqi, kioslave5, gdb. Fedora processes use the drop-in configuration file /usr/lib/systemd/user/service.d/10-timeout-abort.conf which had TimeoutStopFailureMode=abort which makes processes abort when timing out to generated core dumps https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer I changed the timeout to TimeoutSec=120sec, logged out and logged in. I reproduced the plasmashell crash, and the trace completed after about 40 s. drkonqi, plasmashell, and kioslave5 were aborted after 120 s. The default timeout of 40 s for plasma-plasmashell.service wasn't long enough to trace plasmashell and report the crash. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 --- Comment #6 from Matt Fagnani --- There are systemd service watchdog timeouts which default to 45 s like DefaultTimeoutStopSec=45s in man systemd-user.conf. The drkonqi and gdb aborts did usually happen about 45 s after the plasmashell crashes This timeout might explain the plasma-plasmashell.service: State 'stop-sigterm' timed out. Aborting. and the plasmashell, drkonqi, kioslave5, gdb crashes that resulted. I tried to increase the timeout in /etc/systemd/user.conf to DefaultTimeoutStopSec=120s and rebooted. I couldn't reproduce the plasmashell crash when that happened, but I can try it again. I reproduced the plasmashell crash before that and ran gdb -p $(pidof drkonqi) from Konsole then tried to create a trace of plasmashell. The trace of drkonqi when it aborted appeared to have all of its threads waiting. Thread 1 "drkonqi" received signal SIGABRT, Aborted. 0x7facae321bcd in __GI___poll (fds=0x559976bad470, nfds=4, timeout=53546) at ../sysdeps/unix/sysv/linux/poll.c:29 29return SYSCALL_CANCEL (poll, fds, nfds, timeout); (gdb) thread apply all bt Thread 16 (Thread 0x7fac59e296c0 (LWP 14297) "drkonqi:sh1"): #0 0x7facae2a5169 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55997610d764) at futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x55997610d764, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87 #2 0x7facae2a51ef in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55997610d764, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139 #3 0x7facae2a7b09 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=, cond=0x55997610d738) at pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x55997610d738, mutex=) at pthread_cond_wait.c:618 #5 0x7fac8db6abfd in cnd_wait (cond=, mtx=) at ../src/c11/impl/threads_posix.c:135 #6 0x7fac8db1962b in util_queue_thread_func (input=input@entry=0x7fac5005e990) at ../src/util/u_queue.c:290 #7 0x7fac8db6ab2c in impl_thrd_routine (p=) at ../src/c11/impl/threads_posix.c:67 #8 0x7facae2a8897 in start_thread (arg=) at pthread_create.c:444 #9 0x7facae32f6fc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 Thread 15 (Thread 0x7fac5aa616c0 (LWP 14296) "QSGRenderThread"): #0 0x7facae2a5169 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x559976053424) at futex-internal.c:57 --Type for more, q to quit, c to continue without paging--c #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x559976053424, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87 #2 0x7facae2a51ef in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x559976053424, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139 #3 0x7facae2a7b09 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=, cond=0x5599760533f8) at pthread_cond_wait.c:503 #4 ___pthread_cond_wait (cond=0x5599760533f8, mutex=) at pthread_cond_wait.c:618 #5 0x7facae8fb877 in QWaitConditionPrivate::wait (deadline=..., this=0x5599760533d0) at thread/qwaitcondition_unix.cpp:146 #6 QWaitCondition::wait (this=this@entry=0x7fac9800df58, mutex=mutex@entry=0x7fac9800df50, deadline=...) at thread/qwaitcondition_unix.cpp:225 #7 0x7fac97a4b67a in QSGRenderThreadEventQueue::takeEvent (wait=true, this=0x7fac9800df48) at scenegraph/qsgthreadedrenderloop.cpp:257 #8 QSGRenderThread::processEventsAndWaitForMore (this=this@entry=0x7fac9800deb0) at scenegraph/qsgthreadedrenderloop.cpp:935 #9 0x7fac97a4dbcd in QSGRenderThread::run (this=0x7fac9800deb0) at scenegraph/qsgthreadedrenderloop.cpp:1052 #10 0x7facae8f5bbd in operator() (__closure=) at thread/qthread_unix.cpp:350 #11 (anonymous namespace)::terminate_on_exception > (t=) at thread/qthread_unix.cpp:287 #12 QThreadPrivate::start (arg=0x7fac9800deb0) at thread/qthread_unix.cpp:310 #13 0x7facae2a8897 in start_thread (arg=) at pthread_create.c:444 #14 0x7facae32f6fc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 Thread 14 (Thread 0x7fac5b2626c0 (LWP 14295) "drkonqi:gl0"): #0 0x7facae2a5169 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5599769992d8) at futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5599769992d8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87 #2
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 Harald Sitter changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |BACKTRACE --- Comment #5 from Harald Sitter --- Alas, I can't do anything without a trace, sorry. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 --- Comment #4 from Matt Fagnani --- (In reply to Harald Sitter from comment #3) > You haven't posted a drkonqi backtrace though? There wasn't a drkonqi trace for the crash when creating the plasmashell trace because drkonqi crashed the second time when creating the drkonqi trace as I reported in "Another drkonqi window appeared for the drkonqi trace. I pressed Developer Information again in drkonqi. drkonqi crashed again." After reproducing the problem again twice, I think the trace involving File "/usr/share/drkonqi/gdb/preamble.py", line 518, in qml_trace_frame at the end of the summary section on my report was from the second drkonqi crash when creating the trace of the previous drkonqi crash. The following similar trace only appeared in the journal after I selected Developer Information in drkonqi to create the trace for the first drkonqi crash, but not when I didn't try to create the trace of the first drkonqi crash at a different time going through the reproduction steps. Dec 09 21:24:47 plasmashell[6584]: Traceback (most recent call last): Dec 09 21:24:47 plasmashell[6584]: File "", line 1, in Dec 09 21:24:47 plasmashell[6584]: File "/usr/share/drkonqi/gdb/preamble.py", line 620, in print_preamble Dec 09 21:24:47 plasmashell[6584]: print_qml_trace() Dec 09 21:24:47 plasmashell[6584]: File "/usr/share/drkonqi/gdb/preamble.py", line 578, in print_qml_trace Dec 09 21:24:47 plasmashell[6584]: ret = qml_trace_frame(frame) Dec 09 21:24:47 plasmashell[6584]: ^^ Dec 09 21:24:47 plasmashell[6584]: File "/usr/share/drkonqi/gdb/preamble.py", line 510, in qml_trace_frame Dec 09 21:24:47 plasmashell[6584]: value = symbol.value(frame) Dec 09 21:24:47 plasmashell[6584]: ^^^ Dec 09 21:24:47 plasmashell[6584]: KeyboardInterrupt Dec 09 21:24:47 plasmashell[6584]: /tmp/drkonqi.qnFYEn:3: Error in sourced command file: Dec 09 21:24:47 plasmashell[6584]: Error while executing Python code. Dec 09 21:24:47 systemd[3541]: plasma-plasmashell.service: Failed with result 'timeout'. Dec 09 21:24:47 systemd[3541]: plasma-plasmashell.service: Consumed 1min 58.780s CPU time. Dec 09 21:24:47 systemd[3541]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 3. Dec 09 21:24:47 systemd[3541]: Starting plasma-plasmashell.service - KDE Plasma Workspace... The creation of the trace for the plasmashell crash took 20-40 seconds and appeared to get SIGTERM sent to plasma-plasmashell.service which timed out instead of terminating and resulted in SIGABRT being sent to plasmashell, drkonqi, kioslave5, and gdb. I don't know what specifically during the plasmashell trace creation resulted in the SIGTERM being sent to plasma-plasmashell.service. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 --- Comment #3 from Harald Sitter --- You haven't posted a drkonqi backtrace though? -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 Matt Fagnani changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Matt Fagnani --- (In reply to Harald Sitter from comment #1) > I am not quite following. If gdb crashes drkonqi cannot possibly present a > backtrace. Your expected result can just not happen, can it? I expected that drkonqi wouldn't have crashed when creating a trace for the plasmashell crash, which I didn't write but was implied, and then that drkonqi would have shown the trace. plasma-plasmashell.service appeared to time out when responding to SIGTERM in the journal message I included "plasma-plasmashell.service: State 'stop-sigterm' timed out. Aborting"; that message seemed to happen when drkonqi was creating the plasmashell trace which usually was ongoing for at least 20 seconds when the crashes happened. plasmashell, drkonqi, kioslave5, and gdb were aborted right after that based on the plasma-plasmashell.service timeout. I'm unsure if that happened for all such crashes, but it might explain the crashes I saw at least in part. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 Harald Sitter changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO CC||sit...@kde.org --- Comment #1 from Harald Sitter --- I am not quite following. If gdb crashes drkonqi cannot possibly present a backtrace. Your expected result can just not happen, can it? -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 478287] drkonqi, kioslave5, and gdb crashed when creating traces of plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=478287 Bug Janitor Service changed: What|Removed |Added Severity|normal |crash -- You are receiving this mail because: You are watching all bug changes.
