https://bugs.kde.org/show_bug.cgi?id=380495
--- Comment #3 from [email protected] --- Here is some additional info for more clarity: Actually the attached patch just changes ksplashqml to simulate pre-5.3.90 behavior, where it does not emit log anywhere (because it had closed all the file descriptors). The only difference is that SplashApp's file descriptors 0, 1 and 2 are open during its initialization phase. The ksplashqml's caller is /usr/bin/startkde (symlinked by /usr/bin/x-session-manager in a fresh Debian KDE desktop installation), at line 187: > ksplash_pid=`ksplashqml "${ksplashrc_ksplash_theme}" --pid` The caller hangs at this point. As in the previous comment it is reading file descriptor 3, which is apparently the stdout of the ksplashqml process, and is waiting forever, which means the pipe is not closed and is empty. The pipe's file descriptor (writer side) is shared through fork. A small main.c and small caller script attached are a minimal example of the situation. The caller expects that ksplashqml with "--pid" option emit the pid string of its forked process and immediately exit. In reality the ksplashqml process emits the string, but its forked process also holds the pipe and does not close. Thus it hangs. The forked process must not write anything to the pipe, otherwise the caller reads it after the (expected) pid string. So in order to only fix the problem closing (replacing) stdout should suffice. ksplashqml splash app is a qt5 QGuiApplication, which by default loads QPlatformInputContext (input method) plugins. This is why ksplashqml launches an input method system. -- You are receiving this mail because: You are watching all bug changes.
