[ FAIL ] kj/async-io-test.c++:307: legacy test: AsyncIo/AncillaryMessageHandler (1735 μs)

[yousong]

This was reported before #1349

The kernel version 4.4.180-2.el7.elrepo.x86_64

Run the test alone:

➜  ~/git-repo/build-scripts/build_dir/capnproto-c++-0.9.1 git:(master) ./capnp-test --verbose --filter=kj/async-io-test.c++:307
[ TEST ] kj/async-io-test.c++:307: legacy test: AsyncIo/AncillaryMessageHandler
kj/async-io-test.c++:364: failed: expected serverHandlerCalled
stack: 6d8e3a 7f005c90f10f 7f005c8b68f8 7f005c90fe31 7f005c91067d 7f005c8e5a9f 7f005c8b68f8 7f005c8e1c71 7f005c90e49c 7f005c333b74 49080d
[ FAIL ] kj/async-io-test.c++:307: legacy test: AsyncIo/AncillaryMessageHandler (1735 μs)
1 test(s) failed

Attached is output of strace -f -tt ./capnp-test --verbose --filter=kj/async-io-test.c++:307 2>y.txt

y.txt

[kentonv]

Unfortunately, I don't have any new thoughts since the previous thread.

[yousong]

I will see if I can find time for debugging further in my local environment. I tried the same capnp-test binary on a centos 8 with kernel 4.18.0-305.3.1.el8.x86_64 and it passed the test fine there. So likely it's something with my local kernel.

[yousong]

Not 100% sure, but it seems SO_TIMESTAMP for tcp is only available since linux kernel 4.14.: torvalds/linux@98aaa913b4ed250

[kentonv]

Doh. I guess we need to add some sort of code to the test which checks whether SO_TIMESTAMP is supported by the kernel and skips the test if not. Or look for yet another ancillary message type which might work better.

[kentonv]

FYI @a-robinson

[a-robinson]

Ah, I'm sorry @yousong. I didn't think to check when SO_TIMESTAMP had been introduced when I added the test that uses it. I can check for an alternative message type and try to change it over soon, although if you have suggestions they're welcome.

Alternatively, it looks like kernel 4.4 goes end-of-life next month and 4.9 goes end-of-life in 12 months, so this is my favorite kind of bug -- one that will automatically fix itself if you ignore it long enough 😛

[kentonv]

Alternatively, it looks like kernel 4.4 goes end-of-life next month and 4.9 goes end-of-life in 12 months, so this is my favorite kind of bug -- one that will automatically fix itself if you ignore it long enough

Hah... I think given this I'm going to go with "just ignore the test failure if you're running on a very old kernel"... But if someone wants really wants to create a PR to add some checks and skip the test I'll accept it.