Strange phpdbg failures on Travis

[maks-rafalko]

This PR shows, how adding three (almost empty) files lead to phpdbg fails on Travis.

Build: https://travis-ci.org/infection/infection/builds/489218026
Error: https://travis-ci.org/infection/infection/jobs/489218030#L3136-L3142

The process "'/home/travis/.phpenv/versions/7.1.11/bin/phpdbg' '-qrr'
         '/hom                                                                  
                                                                                
         e/travis/build/infection/infection/tests/Fixtures/e2e/Custom_tmp_dir/ve
         ndor                                                                   
           /phpunit/phpunit/phpunit' '--version'" exceeded the timeout of 60    
         seconds.   

I started investigating this issue because of these strange fails in my latest PR: #618

I've been trying many different things but with no luck.

What is interesting, when I connect to the failed build via Travis Debug feature, running command by command from our .travis.yml file, the issue is not reproduced - build is always successfully finished.

To be honest, I have no more ideas what to do.. Spent too much time on it.

This is a critical issue since it blocks any new PR that adds new files, including #618.

Advice would be much appreciated.

[BackEndTea]

Short-term solution, to allow us to continue development, would be to temporary drop phpdbg support.

[BackEndTea]

Also we've had issues with phpdbg before, which weren't really fixed: #429

[maks-rafalko]

Ok, the current status of this issue:

1. master branch is green
2. any new added files lead to failures on Travis for phpdbg
3. This PR (the first commit in it) clearly shows that empty classes and tests with assertSame(1, 1) lead to weird timeout errors on Travis with phpdbg. Example: https://travis-ci.org/infection/infection/jobs/490944947#L3585-L3585

Context:

• we have end-to-end tests that we run simply by bash script
• to increase code coverage, we also run these bash scripts from PHPUnit (not all, but the simplest ones). E2ETest.php

Error happens when we run PHPUnit on Travis with phpdbg, and this E2ETest in its turn runs end-to-end tests from PHPUnit.

The command that starts the process on Travis is trivial:

/home/travis/.phpenv/versions/7.1.11/bin/phpdbg -qrr vendor/bin/phpunit --coverage-clover=clover.xml --coverage-xml=coverage/coverage-xml --log-junit=coverage/phpunit.junit.xml

Then E2ETest.php starts executing e2e tests and one of them fails with:

The process "'/home/travis/.phpenv/versions/7.1.11/bin/phpdbg' '-qrr'
         '/home/travis/build/infection/infection/tests/Fixtures/e2e/Custom_tmp_dir/ve
         ndor/phpunit/phpunit/phpunit' '--version'" exceeded the timeout of 60    
         seconds.

(this is a process started from PHPUnit runtime)

Exactly the same command works well if I remove C1, C2 files (on master branch)

---

The last commit of this branch skips E2ETest.php's tests for phpdbg and it obviosuly "fixes" the issue.

I'm happy to merge it and stop wasting so much time. This explanation is for history and for @krakjoe as there was a tweet asking for help and Joe answered to it

[maks-rafalko]

Had a discussion on Slack and decided to not run e2e from PHPUnit for phpdbg anymore.

from Joe Watkins:

I did try to reproduce the issue, I wrote the core of phpdbg and am intimately familiar with it, I'm also aware that aside from mistakes in coverage (which I did not write) it has bugs that may also be effecting you and are stopping me from even doing a full run locally, there's some problem with too many open file handles, class not found and such, this all seems to be connected to your current headache ...

Closed via 4f2a828

[sanmai]

This seems to be a related issue: travis-ci/travis-ci#9706

Also, IIRC recently Travis CI force-upgraded everyone to use newer infrastructure. The above issue also mentions phpdbg. I haven't dug deeper though. The solution could have been as simple as ulimit -n 64000

[kabalin]

Just noticed this discussion while searching for the simialr issue in travis. I think it is addressed here: php/php-src#3965 Setting php version to 7.2.18 in travis fixed the issue for me.