On Sun, Jan 23, 2011 at 4:41 AM, Thiago Macieira <thiago@kde.org> wrote:
On Saturday, 22 de January de 2011 17:16:10 Dawit A wrote:
> The above snippet of code is something I clipped from
> http://git.videolan.org/?p=vlc.git;a=blob;f=bin/vlc.c;h=70eeed0d2299e2f3cf0c
> 2f6819120f02d0703152;hb=HEAD
>
> One cannot easily tell where QCoreApplication's ctor is getting
> called, but I suspect it is sometime after the call to libvlc_new(...)
> at line #201 and hence after all these signal blocking has occurred ??
> Since I was really not sure and did not want to waste to much time
> mucking around in a rather large and complex code base, I actually
> created a small test case to simulate the condition. I can clean that
> up and post it here if you want.
>
> Oh and the code that instantiates QCoreApplication seems to be located
> around line #533 in:
> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/gui/qt4/qt4.cpp;h=e27c4e
> d33161c1979db7fbe6f1d0f466db1c7e09;hb=HEAD

Well, there are two components here: the signal handler and the signal mask.

The line:
       signal(SIGCHLD, SIG_DFL);

unsets the handler. It's bad if it's called after QCoreApplication. If it's
called before, it's harmless.

However, if all signals are blocked (and they seem to be), then the signal
handler is installed but never called.

That is exactly what happens. Defaulting the SIGCHLD handler is really a non-issue since it is highly likely done way before QCoreApplication is called. However, the call to the pthread_sigmask to block both SIGCHLD and SIGPIPE amongst others is what causes problem for QProcess. Having said that though I have to take up an issue with the fact that there is not a single line of commentary on this huge pitfall in the QProcess documentation ? Why ? Is that because it is an internal implementation detail ? 

Anyhow, after reading the response of one of the VLC developers in bug report I listed in the original email, I am convinced that the reliance on signals, which can so easily get cleared or worse blocked, in a library class seems a really bad idea. It is almost inevitable something like this was bound to happen. Oh well... I doubt there is anything we can do about this in kdelibs short of finding a way to avoid the calling the function that relies on QProcess, which is futile because there are a lot of other places in kdelibs that depend on it too.