compression/070-encoder-pool-reuse was killed by the harness timeout on the
Windows job of run 32942285380, with no output at all:
---- EXPECTED OUTPUT
ok: 30/30
bad-magic: 0
mismatches: 0
Done
---- ACTUAL OUTPUT
** ERROR: process timed out **
Not a wrong answer — the process produced nothing and was killed, so the server
either never started serving or hung on one of the 30 sequential gzip responses.
The rerun of the same job on the same commit passed, and the test does not appear
in any earlier Windows failure list, so one hang in two runs is all that is known.
It came with a branch touching _h2_client.inc, chaos/001, compression/060
and tls/006; 070 uses none of them and no HTTP/2 client, so the change is not
a plausible cause.
Why there is no loop yet
The test skips on a local Windows build — it decodes the response with the zlib
extension, which that build does not have. Reproducing it needs either a Windows
build with zlib enabled or a run under the CI image.
Filed so the next occurrence has something to be added to rather than being
read as the first. If it recurs, the artifact to keep is the .log and whatever
the server wrote before the kill; a hang with no output points at startup or at
the first response, not at the pool reuse the test is named for.
compression/070-encoder-pool-reusewas killed by the harness timeout on theWindows job of run 32942285380, with no output at all:
Not a wrong answer — the process produced nothing and was killed, so the server
either never started serving or hung on one of the 30 sequential gzip responses.
The rerun of the same job on the same commit passed, and the test does not appear
in any earlier Windows failure list, so one hang in two runs is all that is known.
It came with a branch touching
_h2_client.inc,chaos/001,compression/060and
tls/006;070uses none of them and no HTTP/2 client, so the change is nota plausible cause.
Why there is no loop yet
The test skips on a local Windows build — it decodes the response with the zlib
extension, which that build does not have. Reproducing it needs either a Windows
build with zlib enabled or a run under the CI image.
Filed so the next occurrence has something to be added to rather than being
read as the first. If it recurs, the artifact to keep is the
.logand whateverthe server wrote before the kill; a hang with no output points at startup or at
the first response, not at the pool reuse the test is named for.