Bug#862558: plasma-workspace: Freezes during login with fresh installed Stretch Japanese environment
Followup-For: Bug #862558 Dear maintainer, I plan to NMU plasma-workspace if the release team approves the attached patch. (Unblock request #864067) Best regards, Nobuhiro 2017-05-31 23:38 GMT+09:00 YOSHINO Yoshihito: > Followup-For: Bug #862558 > Control: reassign -1 plasma-workspace > Control: affects -1 uim-qt5 uim-mozc > Control: tags -1 + patch > > Dear Maintainer, > > This is a bug in ksplashqml. An upstream commit > https://cgit.kde.org/plasma-workspace.git/commit/?id=56d2c15b9acb9c4b57398b281685807c3191f622 > has caused this problem. > > x-session-manag,133,kdetest /usr/bin/x-session-manager > ├─(ksplashqml,232) > ├─ssh-agent,191 /usr/bin/im-launch x-session-manager > ├─uim-toolbar,220 > │ ├─{llvmpipe-0},235 > │ ├─{llvmpipe-1},236 > │ ├─{llvmpipe-2},237 > │ └─{llvmpipe-3},238 > └─uim-xim,219 > ksplashqml,233,kdetest Breeze --pid > ├─mozc_server,239 > │ ├─{IPCServer},244 > │ ├─{QueueTimer},240 > │ ├─{QueueTimer},243 > │ └─{WatchDog},242 > ├─uim-candwin-qt5,245 -v > │ ├─{QDBusConnection},249 > │ └─{QXcbEventReader},248 > ├─{QDBusConnection},255 > ├─{QQmlThread},254 > ├─{QXcbEventReader},234 > ├─{llvmpipe-0},250 > ├─{llvmpipe-1},251 > ├─{llvmpipe-2},252 > └─{llvmpipe-3},253 > > # strace -f -p 133 > strace: Process 133 attached > read(3, ^Cstrace: Process 133 detached > > > It looks like the parent process (133), x-session-manager (startkde > script), is waiting for the stdout of the ksplashqml process (232), > but which is now defunct. Its child process(es) may be writing to the > same fd. > > # ls -l /proc/133/fd/3 > lr-x-- 1 kdetest kdetest 64 May 31 05:13 /proc/133/fd/3 -> pipe:[88694] > > The direct child of the ksplashqml process (233), the splash screen daemon, > closes the file descriptor at ksplash/ksplashqml/main.cpp:97. > > # ls -l /proc/233/fd/1 > ls: cannot access '/proc/233/fd/1': No such file or directory > > One of the children of the process (239), mozc_server, is holding the fd: > > # ls -l /proc/239/fd/1 > l-wx-- 1 kdetest kdetest 64 May 31 05:14 /proc/239/fd/1 -> pipe:[88694] > > So the startkde process has finished reading the pid number string from > the now-defunct process, but is still waiting for another write(s) until > the (shared) fd has been closed. > > This mozc_server process has been started during uim-qt5 > (a QPlatformInputContext) startup in the SplashApp > initialization phase at ksplash/ksplashqml/main.cpp:92. > > Due to the upstream commit the splash screen daemon does not close file > descriptors before the SplashApp initialization, thus its subprocess > shares the fds. > > The commit log states Wayland initialization of this daemon needs the > channels. While it may require open file descriptors 0, 1 or 2, > no one should expect the process to talk to the parent through the > descriptors, since the splash screen is a daemon. > > An attached patch reverts the commit and redirects the file descriptors > to /dev/null. > > Regards, > -- > YOSHINO Yoshihito -- Nobuhiro Iwamatsu iwamatsu at {nigauri.org / debian.org} GPG ID: 40AD1FA6 plasma-workspace_5.8.6-2.1.debdiff Description: Binary data
Bug#862558: plasma-workspace: Freezes during login with fresh installed Stretch Japanese environment
Followup-For: Bug #862558 Control: reassign -1 plasma-workspace Control: affects -1 uim-qt5 uim-mozc Control: tags -1 + patch Dear Maintainer, This is a bug in ksplashqml. An upstream commit https://cgit.kde.org/plasma-workspace.git/commit/?id=56d2c15b9acb9c4b57398b281685807c3191f622 has caused this problem. x-session-manag,133,kdetest /usr/bin/x-session-manager ├─(ksplashqml,232) ├─ssh-agent,191 /usr/bin/im-launch x-session-manager ├─uim-toolbar,220 │ ├─{llvmpipe-0},235 │ ├─{llvmpipe-1},236 │ ├─{llvmpipe-2},237 │ └─{llvmpipe-3},238 └─uim-xim,219 ksplashqml,233,kdetest Breeze --pid ├─mozc_server,239 │ ├─{IPCServer},244 │ ├─{QueueTimer},240 │ ├─{QueueTimer},243 │ └─{WatchDog},242 ├─uim-candwin-qt5,245 -v │ ├─{QDBusConnection},249 │ └─{QXcbEventReader},248 ├─{QDBusConnection},255 ├─{QQmlThread},254 ├─{QXcbEventReader},234 ├─{llvmpipe-0},250 ├─{llvmpipe-1},251 ├─{llvmpipe-2},252 └─{llvmpipe-3},253 # strace -f -p 133 strace: Process 133 attached read(3, ^Cstrace: Process 133 detached It looks like the parent process (133), x-session-manager (startkde script), is waiting for the stdout of the ksplashqml process (232), but which is now defunct. Its child process(es) may be writing to the same fd. # ls -l /proc/133/fd/3 lr-x-- 1 kdetest kdetest 64 May 31 05:13 /proc/133/fd/3 -> pipe:[88694] The direct child of the ksplashqml process (233), the splash screen daemon, closes the file descriptor at ksplash/ksplashqml/main.cpp:97. # ls -l /proc/233/fd/1 ls: cannot access '/proc/233/fd/1': No such file or directory One of the children of the process (239), mozc_server, is holding the fd: # ls -l /proc/239/fd/1 l-wx-- 1 kdetest kdetest 64 May 31 05:14 /proc/239/fd/1 -> pipe:[88694] So the startkde process has finished reading the pid number string from the now-defunct process, but is still waiting for another write(s) until the (shared) fd has been closed. This mozc_server process has been started during uim-qt5 (a QPlatformInputContext) startup in the SplashApp initialization phase at ksplash/ksplashqml/main.cpp:92. Due to the upstream commit the splash screen daemon does not close file descriptors before the SplashApp initialization, thus its subprocess shares the fds. The commit log states Wayland initialization of this daemon needs the channels. While it may require open file descriptors 0, 1 or 2, no one should expect the process to talk to the parent through the descriptors, since the splash screen is a daemon. An attached patch reverts the commit and redirects the file descriptors to /dev/null. Regards, -- YOSHINO Yoshihito--- plasma-workspace-5.8.6.orig/ksplash/ksplashqml/main.cpp +++ plasma-workspace-5.8.6/ksplash/ksplashqml/main.cpp @@ -24,6 +24,9 @@ #include #include +#include +#include +#include #include void logMessageHandler(QtMsgType type, const char *msg) @@ -83,6 +86,16 @@ int main(int argc, char **argv) return 0; } + +int devNull = open("/dev/null", O_RDWR); +if (devNull == -1) { +return -1; +} +// replace stdin,stdout,stderr, otherwise startkde will block +dup2(devNull, 0); +dup2(devNull, 1); +dup2(devNull, 2); +close(devNull); } //enable to send log output to /tmp/ksplash @@ -91,13 +104,6 @@ int main(int argc, char **argv) QQuickWindow::setDefaultAlphaBuffer(true); SplashApp app(argc, argv); -if (!test && !nofork) { -// close stdin,stdout,stderr, otherwise startkde will block -close(0); -close(1); -close(2); -} - return app.exec(); }
Bug#862558: plasma-workspace: Freezes during login with fresh installed Stretch Japanese environment
Control: reassign -1 uim-qt5 Control: affects -1 uim-mozc plasma-workspace Control: forwarded -1 https://github.com/uim/uim/issues/105 It may be caused by uim-qt5. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature
Bug#862558: plasma-workspace: Freezes during login with fresh installed Stretch Japanese environment
Source: plasma-workspace Severity: grave Justification: renders package unusable Dear Maintainers, After installation of Strech on Japanese environment, ksplashqml stops during login. At that time, process was like below or just status. 1511 ?Sl 0:22 ksplashqml Breeze --pid 1526 ?Sl 0:00 \_ /usr/lib/mozc/mozc_server 1532 ?Sl 0:00 \_ /usr/lib/x86_64-linux-gnu/uim/uim-candwin-qt5 -v Then kill mozc-server process, then I could see desktop. I'm not sure why ksplashqml need to talk to Input method server directly. Step to reproduce) 1. Install Stretch 2. Select Japanese environment 3. Select KDE for desktop and ssh-server 4. After installation, just login (and freezes) 5. Login from ssh client and kill mozc_server process