Bug#862558: plasma-workspace: Freezes during login with fresh installed Stretch Japanese environment

2017-06-03 Thread Nobuhiro Iwamatsu 
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

2017-05-31 Thread 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 
--- 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

2017-05-28 Thread dai 
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

2017-05-14 Thread Hideki Yamane 
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