Running on 7.4beta1 leads to notices while trying to run PHPUnit tests? #762

Ocramius · 2019-07-28T19:01:37Z

Question	Answer
Infection version	0.13.4
Test Framework version	PHPUnit 8.2.5
PHP version	PHP 7.4.0-dev (cli) (built: Jul 27 2019 09:27:41) ( ZTS )
Platform	Ubuntu
Github Repo	https://github.com/Ocramius/ProxyManager

I cannot seem to reproduce this locally, but I get this notice during infection/infection runs on travis-ci:

Notice: stream_get_contents(): read of    
         8192 bytes failed with errno=9 Bad file descriptor in Standard input   
         code on line 321

See https://travis-ci.org/Ocramius/ProxyManager/jobs/564695820#L2102-L2107

"Bad file descriptor"

This may be referring to a closed file handle?

I already run with -vvv, so maybe I can try further flags to make the build in CI more verbose?

The text was updated successfully, but these errors were encountered:

sanmai · 2019-07-30T02:14:56Z

Is it correct to say that you can reliably reproduce this issue on Travis CI?

sanmai · 2019-07-30T02:37:44Z

So far I can't get the package to complete the test suite when running from Docker:

git clone https://github.com/Ocramius/ProxyManager; cd ProxyManager
docker run -it --rm -v "$PWD":/opt/ProxyManager -w /opt/ProxyManager php:7.4.0beta1-zts-buster php vendor/bin/phpunit --stop-on-failure --testsuite=unit

I'm getting:

There was 1 failure:

1) ProxyManagerTest\GeneratorStrategy\FileWriterGeneratorStrategyTest::testGenerateWillFailIfTmpFileCannotBeWrittenToDisk
Failed asserting that exception of type "ProxyManager\Exception\FileNotWritableException" is thrown.

sanmai · 2019-07-30T02:42:24Z

Let's try without that test:

rm ./tests/ProxyManagerTest/GeneratorStrategy/FileWriterGeneratorStrategyTest.php

We get a seemingly flawless, as is with no warnings, run:

$ docker run -it --rm -v "$PWD":/opt/ProxyManager -w /opt/ProxyManager php:7.4.0beta1-zts-buster phpdbg -qrr ./vendor/bin/infection -vvv --test-framework-options='--testsuite=unit' --min-msi=84 --min-covered-msi=86 -j2
You are running Infection with phpdbg enabled.
     ____      ____          __  _
    /  _/___  / __/__  _____/ /_(_)___  ____
    / // __ \/ /_/ _ \/ ___/ __/ / __ \/ __ \
  _/ // / / / __/  __/ /__/ /_/ / /_/ / / / /
 /___/_/ /_/_/  \___/\___/\__/_/\____/_/ /_/

Running initial test suite...

PHPUnit version: 8.2.5

  788 [============================] 3 secs

Generate mutants...

Processing source code files: 139/139
Creating mutated files and processes: 621/621
.: killed, M: escaped, S: uncovered, E: fatal error, T: timed out

EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   ( 50 / 621)
EEEEEEEEEEEEEEEEEEEEEEEESSSSSSSEEEESSSSEEEEEEEEEEE   (100 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (150 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (200 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (250 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (300 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (350 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (400 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (450 / 621)
EEEEEEEEEEEEEEESEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (500 / 621)
EESSSSSSSSSSSSSSSSSSSSSEEEEEEEEEEEEEEEEEEEEEEEEEEE   (550 / 621)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE   (600 / 621)
EEEEEEEEEEEEEEEEEEEEE                                (621 / 621)

621 mutations were generated:
       0 mutants were killed
      33 mutants were not covered by tests
       0 covered mutants were not detected
     588 errors were encountered
       0 time outs were encountered

Metrics:
         Mutation Score Indicator (MSI): 94%
         Mutation Code Coverage: 94%
         Covered Code MSI: 100%

Please note that some mutants will inevitably be harmless (i.e. false positives).

Time: 28s. Memory: 42.00MB

But we get a bunch of errors, which is somewhat suspicious.

Ocramius · 2019-07-30T07:24:17Z

Yeah, getting similar results too...

Any flags to dump more details about all this?

sanmai · 2019-07-30T07:32:39Z

There are no extra flag unfortunately (wish there were more output with -vvv!) but adding a debugging bit about here shows this:

[Uncaught ParseError in /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php on line 318]
ParseError: syntax error, unexpected end of file in /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php:318
Stack trace:
#0 /opt/ProxyManager/vendor/composer/ClassLoader.php(322): Composer\Autoload\includeFile('/opt/ProxyManag...')
#1 [internal function]: Composer\Autoload\ClassLoader->loadClass('PHPUnit\\Framewo...')
#2 /opt/ProxyManager/vendor/phpunit/phpunit/src/Util/Configuration.php(989): spl_autoload_call('PHPUnit\\Framewo...')
#3 /opt/ProxyManager/vendor/phpunit/phpunit/src/Util/Configuration.php(902): PHPUnit\Util\Configuration->getTestSuite(Object(DOMElement), '')
#4 /opt/ProxyManager/vendor/phpunit/phpunit/src/TextUI/Command.php(909): PHPUnit\Util\Configuration->getTestSuiteConfiguration('')
#5 /opt/ProxyManager/vendor/phpunit/phpunit/src/TextUI/Command.php(168): PHPUnit\TextUI\Command->handleArguments(Array)
#6 /opt/ProxyManager/vendor/phpunit/phpunit/src/TextUI/Command.php(160): PHPUnit\TextUI\Command->run(Array, true)
#7 /opt/ProxyManager/vendor/phpunit/phpunit/phpunit(61): PHPUnit\TextUI\Command::main()
#8 {main}

but if I try this right at this place right after that error

echo `php -l vendor/phpunit/phpunit/src/Framework/TestSuite.php`;

I get No syntax errors detected

sanmai · 2019-07-30T07:41:53Z

This has something to do with the IncludeInterceptor, which opens TestSuite.php first of all. And this can be a new PHP bug just as well.

sanmai · 2019-07-30T08:51:19Z

I've augmented every method call in the IncludeInterceptor, and appears like PHP reads first 8K bytes from the file, checks for EOF, and even it is false, stops reading and fails with a parse error for an incomplete file.

Opening /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php
stream_open /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php
stream_set_option /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php
stream_set_option stream_set_read_buffer /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php
stream_stat /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php
stream_read /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php (8192)
stream_eof /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php
bool(false)
[Uncaught ParseError in /opt/ProxyManager/vendor/phpunit/phpunit/src/Framework/TestSuite.php on line 318]

This seems to be related:

php/php-src@d59aac5#diff-359a9bc5d709b88d41cd56459a541565

The php_stream_read() and php_stream_write() functions now return an ssize_t value, with negative results indicating failure. Functions like fread() and fwrite() will return false in that case. As a special case, EWOULDBLOCK and EAGAIN on non-blocking streams should not be regarded as error conditions, and be reported as successful zero-length reads/writes instead. The handling of EINTR remains unclear and is internally inconsistent (e.g. some code-paths will automatically retry on EINTR, while some won't). I'm landing this now to make sure the stream wrapper ops API changes make it into 7.4 -- however, if the user-facing changes turn out to be problematic we have the option of clamping negative returns to zero in php_stream_read() and php_stream_write() to restore the old behavior in a relatively non-intrusive manner.

nikic · 2019-07-30T15:02:19Z

Most likely your issue is already fixed by php/php-src@9bfda01.

nikic · 2019-07-30T15:07:13Z

Well, at least the issue mentioned by @sanmai in the last comment, that matches pretty precisely what the referenced commit fixes. The Bad file descriptor error from the original report might have a different root cause though. This is indeed a new error (file I/O errors were previously silently ignored), so there's probably some code trying to read from a non-readable file descriptor.

Ocramius · 2019-07-30T19:59:11Z

Will try re-triggering builds once the next PHP beta is on Travis 👍

nikic · 2019-07-30T20:04:21Z

@Ocramius Travis doesn't use betas, so it should already have the fix in 7.4snapshot :)

Ocramius · 2019-07-30T20:10:33Z

Very much the same output on a new build (https://travis-ci.org/Ocramius/ProxyManager/jobs/564701417):

         1)                                                                     
         ProxyManagerTest\GeneratorStrategy\FileWriterGeneratorStrategyTest::tes
         tGenerateWillFailIfTmpFileCannotBeMovedToFinalDestination              
         PHPUnit\Framework\Exception: Notice: stream_get_contents(): read of    
         8192 bytes failed with errno=9 Bad file descriptor in Standard input   
         code on line 321

PHP version seems to be from today:

PHP 7.4.0-dev (cli) (built: Jul 30 2019 10:11:53) ( ZTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies

sanmai · 2019-07-31T01:10:30Z

Notice: stream_get_contents(): read of 8192 bytes failed with errno=9 Bad file descriptor in Standard input code on line 321

This error is from the initial test run. Infection does nothing about it except telling PHPUnit where to put coverage files. So in theory you should be able to reproduce the exact same issue without Infection.

Ocramius · 2019-07-31T01:16:54Z

Hmm, maybe running phpunit with phpdbg coverage would be sufficient then: will give it a try.

sanmai · 2019-07-31T01:20:53Z

Something like this should do the job:

phpdbg -qrr vendor/bin/phpunit --coverage-xml=build/logs/coverage-xml --log-junit=build/logs/phpunit.junit.xml --coverage-clover=build/logs/clover.xml

And then you can feed that coverage to Infection like so:

php vendor/bin/infection --coverage=build/logs --show-mutations

(Infection uses the same approach to save time on the second test run: it finishes quite faster when not collecting coverage.)

Ocramius · 2019-08-01T12:47:13Z

Hmm, not reproducible locally with just PHPUnit on latest PHP-7.4 (php/php-src@61e1147).

CI failed with the similar errors as reported above with PHP 7.4.0-dev (cli) (built: Jul 31 2019 09:24:31) ( ZTS )

At this point, I guess what's left to be tried is using the travis-ci runner locally, and debugging there...

sanmai · 2019-08-02T01:23:21Z

It shouldn't be a big deal to run remotely, so I did Ocramius/ProxyManager#483. Let's see how it goes.

sanmai · 2019-08-02T01:31:53Z

Strangely enough I can see an issue with PHPUnit only.

So it appears not related to the Infection itself.

sanmai · 2019-08-02T01:38:41Z

We can spend time debugging more, but since the issue appears without Infection even used, I can assume there's nothing we can do Infection-wise to alleviate this error.

If I'm missing something, please correct me. Otherwise please feel free to close as you see fit.

Ocramius · 2019-08-02T05:50:33Z

Closing here: thanks for digging into it, @sanmai!

I will report this on PHPUnit directly 👍

sanmai · 2020-01-29T02:51:13Z

@Ocramius any luck finding the root cause for this issue?

sanmai · 2020-01-29T03:11:41Z

This seems related: sebastianbergmann/phpunit#3965

sanmai · 2020-01-29T03:30:33Z

@Ocramius please never mind the previous comment. The issue seems to be related to PHPDBG incompatibilities with PHPUnit, so the best solution right now seems to be using PCOV for coverage collection.

Ocramius mentioned this issue Jul 28, 2019

Removed reliance on Closure::bind(_, null) Ocramius/ProxyManager#475

Merged

sanmai added the Question label Aug 1, 2019

sanmai mentioned this issue Aug 2, 2019

Try running PHPUnit like Infection does Ocramius/ProxyManager#483

Closed

Ocramius closed this as completed Aug 2, 2019

sanmai mentioned this issue Jan 29, 2020

Errors on PHP 7.4 on Travis infection/include-interceptor#6

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Running on 7.4beta1 leads to notices while trying to run PHPUnit tests? #762

Running on 7.4beta1 leads to notices while trying to run PHPUnit tests? #762

Ocramius commented Jul 28, 2019

sanmai commented Jul 30, 2019

sanmai commented Jul 30, 2019

sanmai commented Jul 30, 2019

Ocramius commented Jul 30, 2019

sanmai commented Jul 30, 2019 •

edited

sanmai commented Jul 30, 2019 •

edited

sanmai commented Jul 30, 2019

nikic commented Jul 30, 2019

nikic commented Jul 30, 2019

Ocramius commented Jul 30, 2019

nikic commented Jul 30, 2019

Ocramius commented Jul 30, 2019

sanmai commented Jul 31, 2019

Ocramius commented Jul 31, 2019

sanmai commented Jul 31, 2019 •

edited

Ocramius commented Aug 1, 2019

sanmai commented Aug 2, 2019

sanmai commented Aug 2, 2019

sanmai commented Aug 2, 2019

Ocramius commented Aug 2, 2019

sanmai commented Jan 29, 2020

sanmai commented Jan 29, 2020

sanmai commented Jan 29, 2020

Running on 7.4beta1 leads to notices while trying to run PHPUnit tests? #762

Running on 7.4beta1 leads to notices while trying to run PHPUnit tests? #762

Comments

Ocramius commented Jul 28, 2019

sanmai commented Jul 30, 2019

sanmai commented Jul 30, 2019

sanmai commented Jul 30, 2019

Ocramius commented Jul 30, 2019

sanmai commented Jul 30, 2019 • edited

sanmai commented Jul 30, 2019 • edited

sanmai commented Jul 30, 2019

nikic commented Jul 30, 2019

nikic commented Jul 30, 2019

Ocramius commented Jul 30, 2019

nikic commented Jul 30, 2019

Ocramius commented Jul 30, 2019

sanmai commented Jul 31, 2019

Ocramius commented Jul 31, 2019

sanmai commented Jul 31, 2019 • edited

Ocramius commented Aug 1, 2019

sanmai commented Aug 2, 2019

sanmai commented Aug 2, 2019

sanmai commented Aug 2, 2019

Ocramius commented Aug 2, 2019

sanmai commented Jan 29, 2020

sanmai commented Jan 29, 2020

sanmai commented Jan 29, 2020

sanmai commented Jul 30, 2019 •

edited

sanmai commented Jul 30, 2019 •

edited

sanmai commented Jul 31, 2019 •

edited