[Interest] QProcess::execute never returning (5.4/5.5 behaviour change)

[Thiago Macieira]

On Sunday 26 July 2015 19:11:55 Alejandro Exojo wrote:
> This works perfectly fine in a test case that just calls execute(), so I
> think the issue is that I'm using the FUSE library. That library calls fork
> and exec, and at some point sets up SIGCHLD in a way that probably prevents
> QProcess from working well (it uses signal instead of sigaction), even if I
> use it in a different thread.

Shoot it in the head.

> That's the part that works partially as wanted with 5.5.0. I call fuse_mount
> (which is the one I suspect it breaks something) at application startup,
> and the first call to QProces::execute() works. If I call fuse_mount again,
> the second call to execute() works, but never returns to the caller.

Sounds like the SIGCHLD handler isn't passing control back to Qt's.

> So, is this a QProcess limitation or a bug? I see the behaviour change
> across versions. Might be that the other library is doing something plain
> unnacceptable for QProcess? I tried replacing QProces::execute() with
> ::system() and it works as expected, though.

There was a slight behaviour change in 5.5: the SIGCHLD handler is installed 
when first needed, instead of when you instantiate QCoreApplication. Another 
important change is that it no longer needs a thread to do it.

It sounds like a bug in the fuse library. I don't see them installing a 
SIGCHLD handler, but they do block it. That can affect forkfd because the old 
QProcessManager, by virtue of having started a thread (any thread!) before the 
fuse library blocked the signal, would not be blocked.

But the fuse library restores the block mask before the function exits, so I 
can't see how that could be the issue.

I need an strace -f log of the issue.

> PD: And thank you Thiago for your blog posts about forkfd. Reading that
> probably was the key that made me figure out what might be wrong with my
> app. Otherwise I would still be hitting my head against the desk. :)

Once I finally get forkfd in the kernel, the problems will be finally fixed. 
Unfortunately, we got something wrong with ptrace and we have no clue what. So 
the process is stalled until someone who understands ptrace volunteers the 
time.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center