Test t/refhang.t failing on s390x #197

guikcd opened this Issue Aug 25, 2016 · 4 comments


None yet

3 participants

guikcd commented Aug 25, 2016

The testsuite fail for the s390x on the buildd Debian system:

t/noreply.t ................. ok

#   Failed test 'some ooms happened'
#   at t/refhang.t line 51.

#   Failed test 'nonzero lrutail_reflocked'
#   at t/refhang.t line 53.
#          got: '0'
#     expected: anything else

#   Failed test 'nonzero total lrutail_reflocked'
#   at t/refhang.t line 56.
#          got: '0'
#     expected: anything else
# Looks like you failed 3 tests of 127.
t/refhang.t ................. 
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/127 subtests 
t/slabs-reassign-chunked.t .. ok

I'll try to give an access to such box to try to investigate this issue, but i can't promise...
I've opened a Debian bug to follow-up this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835456

Source: https://buildd.debian.org/status/fetch.php?pkg=memcached&arch=s390x&ver=1.4.31-1&stamp=1471823136


He. There's even a TODO in there about the send buffers.

Looks like I need to add a test-env-var or similar to set the send buffers to a predictable size... then I can set the receive buffers to a predictable size. then the test shouldn't fail unpredictably.


Sorry it's taken so long for me to come back around to this... Apparently SNDBUF is only modified for UDP sockets. Wiring this in for the test will be more invasive than I hoped.

Can you test adjusting line 56? double the for loop (you'll get a "dubious" fail because of the number of tests changing), or increase it a few times and see if the test will pass at any form? (you probably have to change the "-m 6" there to "-m 64" or so. One option is for it to try a couple passes itself, but it'd be a lot better if I can figure a clean place to clamp the send buffer.


@guikcd did you have a chance to try what @dormando suggested?



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment