By running two QtCreator processes, having the child process delay for 30
seconds, and then attaching to it using the second QtCreator after the process
in the first QtCreator start()'d it, I was able to determine that it was
segfaulting on me during its start-up. It was only doing this when being
launched from the first process (launching it standalone didn't cause this).
So, figured it out. :)
On 11/12/2015 2:54 PM, Thiago Macieira wrote:
On Thursday 12 November 2015 14:33:00 Bob Hood wrote:
I had a look at the code for QProcess, which seems to be doing standard
fork/exec launching of the process, whereas, if I'm not mistaken, popen()
uses the shell to run it. Is that the only difference here? Should I be
running the QProcess version through the shell explicitly then to make it
function?
No, it's not the only difference, but you can try to go through the shell to
see if it solves your problem.
The first thing you have to isolate when there's an I/O problem between
multiple processes (pipes, sockets, etc.) is to isolate which side is at
fault. Your symptom is that QProcess does not report anything ready to read.
Why is that?
Which side is at fault here? Did the child process even write anything to its
pipes? If not, then QProcess is blameless.
One more thing: the two snippets you pasted are not equivalent. For the
QProcess case, you stopped at waitForStarted(), which only reports that the
execve(2) call succeeded. It does not mean the main() function in the child
process has been reached. On the popen case, you pasted code that does the
I/O.
So it's entirely possible there's a bug in your code but it's not in the parts
you pasted.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
