intermittent test failure in foolscap.test.test_call.TestCall.testCall1 on travis+pypy

[Brian Warner]

The travis-ci builder, when running unit tests on pypy, occasionally fails testCall1, like here:

​https://travis-ci.org/warner/foolscap/jobs/36113857

There's not much to go on, it's just a timeout after the test takes more than 120 seconds to complete. I've seen it pass successfully on travis+pypy while taking a surprisingly long time, maybe 60 seconds by my eyeball.

Things to try:

• run this test locally and see if it takes a significant amount of time
• add --reporter=timing to a few runs and see how long a successful run takes on travis+pypy
• install pypy locally and see if it takes more time to run than normal python
• if so, figure out what's taking so long and fix it
• and/or increase the timeout

Based on a small number of samples, I think the failure rate is maybe 40%.

[Brian Warner]

There's another one happening on travis+pypy: foolscap.test.test_negotiate.Crossfire.test5, in ​https://travis-ci.org/warner/foolscap/jobs/36127271 . Not sure if it's related or not.

[FAIL]

Traceback (most recent call last):
  File "/home/travis/build/warner/foolscap/foolscap/test/test_negotiate.py", line 478, in checkConnectedViaReverse
    self.failUnlessEqual(self.tub2phases, targetPhases)
  File "/home/travis/virtualenv/pypy-2.3.1/site-packages/twisted/trial/_synctest.py", line 356, in assertEqual
    % (msg, pformat(first), pformat(second)))
twisted.trial.unittest.FailTest: not equal:
a = []
b = [2]

[Brian Warner]

Another recent one: ​​https://travis-ci.org/warner/foolscap/jobs/55317244 , which shows up in in foolscap.test.test_logging.Publish.test_logpublisher. Feels like an intermittent timing problem, since Foolscap's tests unfortunately don't synchronize very well.

(closed #232 as a dup)

[Brian Warner]

Milestone renamed

[Brian Warner]

Moving these tickets from 0.12 to 0.13, since we need 0.12 out quickly to resolve #263

[Brian Warner]

I'm going to close this now:

• I haven't seen it happen for a while
• current travis can't even build against pypy: cryptography-1.0 is not compatible with pypy2 (or at least the pypy2 that travis has)

If someone has a local pypy environment that can reproduce this, I'd love to figure it out, but for now I think we don't have the tooling to do so.