Summary: | kded5 hangs in QProcess::waitForFinished and does not reap setxkbmap | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kded | Reporter: | Jiri Slaby <jirislaby> |
Component: | general | Assignee: | David Faure <faure> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | a.samirh78, fabian, kdelibs-bugs, mpyne |
Priority: | NOR | ||
Version: | 5.45.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
strace -f of kded5 (packed by xz due to size)
strace -f of kded5 (packed by xz due to size) |
Description
Jiri Slaby
2018-05-17 08:35:39 UTC
How well can you reproduce the issue? Can you try to strace -f kded5 while it happens? (In reply to Fabian Vogt from comment #1) > How well can you reproduce the issue? Can you try to strace -f kded5 while > it happens? Not really well. Could you tell me what event triggers the stack trace? BTW I have just updated to 5.12.5 because I could not find -debuginfo for plasma5-desktop-5.12.4 from Tumbleweed anymore. When this happens again, I will have better stack trace (#8 and #9 filled in the trace too). (In reply to Jiri Slaby from comment #2) > (In reply to Fabian Vogt from comment #1) > > How well can you reproduce the issue? Can you try to strace -f kded5 while > > it happens? > > Not really well. Could you tell me what event triggers the stack trace? connect(xEventNotifier, &XInputEventNotifier::newKeyboardDevice, this, &KeyboardDaemon::configureKeyboard); i.e. plugging in a keyboard. > BTW I have just updated to 5.12.5 because I could not find -debuginfo for > plasma5-desktop-5.12.4 from Tumbleweed anymore. When this happens again, I > will have better stack trace (#8 and #9 filled in the trace too). I don't think a more detailed stack trace can help here - an strace would be ideal. Created attachment 112709 [details]
strace -f of kded5 (packed by xz due to size)
I cannot reproduce easily. It happened only once during unplug/replug and not in this strace run.
Created attachment 114320 [details] strace -f of kded5 (packed by xz due to size) Now I reproduced even with strace capturing the process. (It still recurs and is painful.) 13987 is kdeinit. 16233 is the pid of the setxkbmap process which became a zombie. 16213 is the last process which kdeinit called wait4 for. It is another instance of setxkbmap: > 16213 exit_group(0) = ? > 16213 +++ exited with 0 +++ > 13987 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16213, si_uid=500, si_status=0, si_utime=0, si_stime=1} --- > 13987 waitid(P_ALL, 0, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16213, si_uid=500, si_status=0, si_utime=0, si_stime=0}, WNOHANG|WEXITED|WNOWAIT, NULL) = 0 > 13987 wait4(16213, <unfinished ...> > 13987 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, {ru_utime={tv_sec=0, tv_usec=2524}, ru_stime={tv_sec=0, tv_usec=10098}, ...}) = 16213 setxkbmap is not the only unreaped process. I also saw zombie of xterm pinned to kdeinit (opened via ctrl-alt-t which is a custom shortcut to run xterm). That strace output is very useful: 16233 exit_group(0) = ? 16233 +++ exited with 0 +++ 13987 <... ppoll resumed> ) = ? ERESTARTNOHAND (To be restarted if no handler) 13987 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16233, si_uid=500, si_status=0, si_utime=0, si_stime=0} --- 13987 ppoll([{fd=-1}, {fd=-1}, {fd=-1}, {fd=46, events=POLLIN}], 4, NULL, NULL, 8 <unfinished ...> 13990 <... poll resumed> ) = 1 ([{fd=3, revents=POLLIN}]) If I interpret this correctly, kdeinit was currently doing a ppoll (no sigmask, so == poll) and it had no handler, as otherwise it would've done one of the calls in the handler and not continue with ppoll. This seems to explain it: 13987 rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f0242406110}, NULL, 8) = 0 It's the last call to rt_sigaction in that process, so it removed its signal handler, so it's no surprise it stays a zombie... Now the question is where the rt_sigaction call comes from. It might be somewhere in forkfd. Please try to run kded5 without the glib event loop: kquitapp5 kded5; QT_NO_GLIB=1 kded5 If that works fine, it's probably a bug in either glib itself or in its integration. (In reply to Fabian Vogt from comment #7) > Please try to run kded5 without the glib event loop: > > kquitapp5 kded5; QT_NO_GLIB=1 kded5 > > If that works fine, it's probably a bug in either glib itself or in its > integration. I don't want to be too conclusive now, but after quite few plugs/unplugs of such kded5: # grep -z GLIB /proc/`pidof kded5`/environ; echo QT_NO_GLIB=1 I haven't seen the issue yet. But to me it seems that it is enough to just re-run kded5 after power on: kquitapp5 kded5; kded5 I haven't seen the issue with such a restart too. But I only tried few replugs. If glib integration is an issue, there's a separate Qt bug we're tracking where timer events can be starved in the glib event loop which may be related, at https://bugs.kde.org/show_bug.cgi?id=230184 (In reply to Michael Pyne from comment #9) > If glib integration is an issue, there's a separate Qt bug we're tracking > where timer events can be starved in the glib event loop which may be > related, at https://bugs.kde.org/show_bug.cgi?id=230184 That's unrelated AFAICT - this issue is about glib removing the SIGCHLD handler. Reported upstream as https://bugreports.qt.io/browse/QTBUG-69907 Please re-do the strace with "-e trace=rt_sigaction -k" so that we can see which call chain leads to the glib issue. It might be a bug in Qt, glib, kded or any of the currently loaded modules. (In reply to Jiri Slaby from comment #8) > I don't want to be too conclusive now, but after quite few plugs/unplugs of > such kded5: > # grep -z GLIB /proc/`pidof kded5`/environ; echo > QT_NO_GLIB=1 > > I haven't seen the issue yet. > > But to me it seems that it is enough to just re-run kded5 after power on: > kquitapp5 kded5; kded5 Correct – it is enough to re-run kded5 like this and kded5 no longer spawns children. So neither setxkbmap is exec'ed nor other processes. So unless you have an idea how to run a new (strace'd) instance kded5 which would behave as the one run by the session, I cannot provide the requested info. Might be related to https://mail.kde.org/pipermail/kde-frameworks-devel/2021-January/115829.html |