On Sun, 18 Jan 2015 17:33:40 +0100 Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote: > On 18/01/15 at 23:12 +1100, Stuart Prescott wrote: > > Control: tag -1 unreproducible > > > > A timeout issue like this is often sensitive to the machine used and I > > cannot > > reproduce this FTBFS here -- the test suite also took less than half the > > time > > to run on this old laptop cf the EC2 instance. The three timeout values > > could > > be increased if necessary but that hardly seems worth it. >
It seems to be the same issue as it is with the failing DEP-8 tests on
ci.debian.net [1]. I'm unable to reproduce this myself, but taking a
closer look to AbstractProcessTest::testStartAfterATimeout(), the test
itself is pretty useless:
First: The command that is executed actually is this one:
# php -r "$n = 1000; while ($n--) {echo ''; usleep(1000); }"
This does not wait ~1s, but produces the following error:
PHP Parse error: syntax error, unexpected '=' in Command line code on line 1
Second: Any \Exception is caught in the try{}...catch(), while a
RuntimeException should be caught instead.
Currently even the Exception potentially thrown with
"$this->fail('A RuntimeException should have been raised.');"
is caught, making a mockery out of the whole tests.
> Which timeout values are you talking about?
>
> You seem to think that the problem is that the test is taking too long.
> That doesn't seem to be the case to me: the test's purpose is to test
> stuff related to timeouts in Symfony's Process component.
>
> What seems to happen here is that the call to start() causes a call to
> checkTimeout(), that detects that the process should be timeouted.
> So it's either a matter of start() taking too long to start the process,
> or of insufficient timer accuracy. Assuming that Process can start a
> process in 0.1s might be a bit optimistic.
>
Actually upstream once doubled [2] the timeout to 0.2s, but this got
lost later on - most likely due to resolving merge conflicts.
I'm currently preparing a fixed version of
AbstractProcessTest::testStartAfterATimeout() for upstream.
Afterward I will prepare a new upload for Debian, containing the fix.
I don't think it's needed to double the process timeout, once the test
is working as expected again.
Daniel
[1] http://ci.debian.net/packages/s/symfony/unstable/amd64/
[2]
https://github.com/symfony/symfony/commit/ae8481038e6f7eefc8c39bcc86415438214e12b9?diff=unified#diff-8b27fa124d6320de1b3f9bb9b527a663R588
signature.asc
Description: This is a digitally signed message part
