pypy shards in travisCI can fail with 'too many open files' errors #497
Assignees
Comments
This was referenced May 26, 2018
Merged
|
filed travis-ci/travis-ci#9706 for some upstream help. |
This was referenced Jun 8, 2018
|
topical relief achieved in #513 here: https://travis-ci.org/pantsbuild/pex/builds/390035309 at a cost of ~4x test execution time (~2m -> ~8m) - good enough to tide us over for now. |
kwlzn
added a commit
that referenced
this issue
Jun 9, 2018
|
I found the bug and it is in pypy. I need to work around it for other reasons, and it turns out this fixes our pypy shard which can now run normally. Re-opening to linkup the fix PR and add bug links. |
jsirois
added a commit
to jsirois/pex
that referenced
this issue
Nov 26, 2018
Previously, pex would blow up trying to adjust import paths if a PEP-420 implicit namespace package was encountered. Add a test of the path adjustment functionality both to confirm it was needed (it was) and that the fix technique works with all forms of namespace packages by only assuming they support `append`. To support all this, work around a pypy zipimporter bug: https://bitbucket.org/pypy/pypy/issues/1686 and, as a side-effect, eliminate our CI workaround for the pypy unit test shard. Fixes pex-tool#598 Fixes pex-tool#497
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
this needs more investigation, but intermittently only the "pypy" shards in travis will fail arbitrarily with "too many open files" errors.
we had previously pinned to the travis
preciseimage because of this, but because of deprecation prompting for that image we'd jumped forward here: #476an initial pass may want to try some simple
ulimittuning.The text was updated successfully, but these errors were encountered: