PHP hanging indefinitely

[leopcastro]

I was testing some html conversions using the mikehaertl/phpwkhtmltopdf, when I noticed one made PHP hang indefinitely.

Doing some debug, I found out that it was happening in the php-shellcommand/src/Command.php file at line number 317:

$this->_stdOut = stream_get_contents($pipes[1]); 

After some research, I found a similar problem in this stackoverflow question and an apparent solution. http://stackoverflow.com/questions/31194152/proc-open-hangs-when-trying-to-read-from-a-stream

According to the stackoverflow answer, there is a possibility of an execution not outputting anything to stdout (pipe[1]) when an error occurs, so stream_get_contents waits for a stream that never comes.

As pointed out in the stackoverflow answer, reading the stderr (pipe[2]) before stdout (pipe[1]) did the trick for me, with the PHP finishing execution and the error message being outputted.

$this->_stdErr = stream_get_contents($pipes[2]);
$this->_stdOut = stream_get_contents($pipes[1]); 

My system config:

• Ubuntu 14.04.1 LTS running as a headless VM on Virutalbox
• PHP Version 5.5.22-1+deb.sury.org~trusty+1
• Apache/2.4.12
• wkhtmltopdf 0.12.2 (with patched qt)

[mikehaertl]

@leonardopcastro Released 1.2.3 containing this fix. Thanks for your help!

[mikehaertl]

@leonardopcastro This change seems to have introduced other problems now. See #21.

[mikehaertl]

As proposed in mikehaertl/phpwkhtmltopdf#78 (comment) and again in #9 (comment) we could try to add stream_set_blocking() calls:

$descriptors = array(
    1 => array('pipe','w'),
    2 => array('pipe','w')
);
$process = proc_open($command, $descriptors, $pipes, $this->procCwd, $this->procEnv, $this->procOptions);

if (is_resource($process)) {
    // set streams to non blocking mode
    stream_set_blocking($pipes[1], 0);
    stream_set_blocking($pipes[2], 0);
    $this->_stdOut = trim(stream_get_contents($pipes[1]));
    $this->_stdErr = trim(stream_get_contents($pipes[2]));
    fclose($pipes[1]);
    fclose($pipes[2]);
...

There was one neutral feedback in #78 ("didn't fix it") and we have 2 positive in #6. So maybe we should really implement the fix suggested by @mkloosterman in #78.

I'd feel better if we had reliable test cases that can reproduce the issue. Any volunteers? @schmunk42, @markdboyd, @epicwally?

[markdboyd]

@mikehaertl I'm not sure when I'll have time to get to this, but would a test that reproduces the infinite hanging when trying to read the streams in this order be sufficient? I'm still not 100% clear on what the actual cause of the hanging is, but for me it seemed directly related to the size of the PDFs I was trying to generate.

[mikehaertl]

@markdboyd I'd say the size of the PDF should not matter as the problem seems to be more on the side of the buffers for error and standard message output. So I think it's about the length of the command which of course increases if you have more pages in your PDF (each page == one more argument to wkhtmltopdf).

An ideal test would use some regular shell command (echo, cat, grep, ...) and try to make it hang (e.g. by using a very long option string or letting it output very long strings to stdout / stderr or a combination of everything). When we have this it will probably also point us to the root of the problem.

I can't promise that I find time for this soon - even more so as I never had the issue myself 😛 .