-
-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running on 7.4beta1 leads to notices while trying to run PHPUnit tests? #762
Comments
Is it correct to say that you can reliably reproduce this issue on Travis CI? |
So far I can't get the package to complete the test suite when running from Docker:
I'm getting:
|
Let's try without that test:
We get a seemingly flawless, as is with no warnings, run:
But we get a bunch of errors, which is somewhat suspicious. |
Yeah, getting similar results too... Any flags to dump more details about all this? |
There are no extra flag unfortunately (wish there were more output with
but if I try this right at this place right after that error
I get |
This has something to do with the |
I've augmented every method call in the
This seems to be related: |
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.
Most likely your issue is already fixed by php/php-src@9bfda01. |
Well, at least the issue mentioned by @sanmai in the last comment, that matches pretty precisely what the referenced commit fixes. The |
Will try re-triggering builds once the next PHP beta is on Travis 👍 |
@Ocramius Travis doesn't use betas, so it should already have the fix in 7.4snapshot :) |
Very much the same output on a new build (https://travis-ci.org/Ocramius/ProxyManager/jobs/564701417):
PHP version seems to be from today:
|
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. |
Hmm, maybe running phpunit with phpdbg coverage would be sufficient then: will give it a try. |
Something like this should do the job:
And then you can feed that coverage to Infection like so:
(Infection uses the same approach to save time on the second test run: it finishes quite faster when not collecting coverage.) |
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 At this point, I guess what's left to be tried is using the travis-ci runner locally, and debugging there... |
It shouldn't be a big deal to run remotely, so I did Ocramius/ProxyManager#483. Let's see how it goes. |
Strangely enough I can see an issue with PHPUnit only. So it appears not related to the Infection itself. |
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. |
Closing here: thanks for digging into it, @sanmai! I will report this on PHPUnit directly 👍 |
@Ocramius any luck finding the root cause for this issue? |
This seems related: sebastianbergmann/phpunit#3965 |
@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. |
I cannot seem to reproduce this locally, but I get this notice during
infection/infection
runs on travis-ci:See https://travis-ci.org/Ocramius/ProxyManager/jobs/564695820#L2102-L2107
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: