test for headers that are too large fails on Debian s390x
I maintain the passenger package on Debian, and I was working on running the test suite during the package build and against the installed package. It turns out I found one test failure under the s390x architecture:
Failures:
1) PhusionPassenger::RequestHandler the main socket rejects headers that are too large
Failure/Error: block.should raise_error(Errno::EPIPE)
expected Errno::EPIPE but nothing was raised
# ./ruby/request_handler_spec.rb:95:in `block (2 levels) in <module:PhusionPassenger>'
Finished in 5.5 seconds (files took 0.23326 seconds to load)
53 examples, 1 failure
Failed examples:
rspec ./ruby/request_handler_spec.rb:81 # PhusionPassenger::RequestHandler the main socket rejects headers that are too large
This is consistently reproducible. Please let me know if there's any information I can provide to help debug this. I can tests patches on this architecture if necessary.
Here is the full s390x build log
The general idea of this test is that the test writes more into a request than the request handler is set to take, the request handler reads as much as it can, sees the overflow, returns false to indicate failure and then the connection is closed, whereupon the rest of the write causes an EPIPE.
https://github.com/phusion/passenger/blob/stable-6.0/test/ruby/request_handler_spec.rb#L93 https://github.com/phusion/passenger/blob/stable-6.0/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb#L143 https://github.com/phusion/passenger/blob/stable-6.0/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb#L214-L216 https://github.com/phusion/passenger/blob/stable-6.0/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb#L171-L173 https://github.com/phusion/passenger/blob/stable-6.0/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb#L196-L207
Perhaps the write on the s390x is buffered or something so that it can write the whole message before any is read out, therefore not writing after the socket is closed, and therefore not triggering the EPIPE?
FWIW it seems it also happens in amd64 (x86_64): https://ci.debian.net/packages/p/passenger/testing/amd64/56974804/#L943
(this link expires after a couple of months)
That leads me to think there's something wrong with your testing setup, we run our tests on debian on amd64 hardware all the time.
You might want to try running the test with the vendored libev, it is modified so perhaps that's why debian's version is acting weird?