search

efficient / libcuckoo

A high-performance, concurrent hash table
Other
1.61k stars 275 forks source link

Strange behavior of tests for different architectures #144

Open txgk opened 2 years ago

txgk commented 2 years ago

Hello, I was trying to package libcuckoo for Alpine Linux and encountered strange behavior of tests for different architectures.

On first GitLab pipeline all architectures passed the tests (except 32-bit ones of course). When the pipeline was run again with the exception of 32-bit architectures, ppc64le failed the tests which is weird, considering that everything went well for it in the first time. Later the same thing happened to aarch64 (this is not reflected in the GitLab pipelines page because it was stopped right after the error).

My question is it really necessary to remove package support for these architectures because of these unstable tests?

You can check which tests failed here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34956/pipelines

manugoyal commented 2 years ago

Hi @txgk, looking at the test failures, they seem to be over the version of libcuckoo that had issues with the test_resize function on 32-bit architectures. This was fixed in https://github.com/efficient/libcuckoo/commit/23624692d146d6d71754b713da11693b9d3b9e5f, so I'm wondering if the tests will pass more stably over a more recent version?

txgk commented 2 years ago

I changed build file to the version of the last commit and now results are https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35004/pipelines Build is now successful for 32-bit architectures, but x86 failed at insert_expansion test. ppc64le and aarch64 failed this test last time too. I think it randomly segfaults no matter what architecture is being tested.

txgk commented 2 years ago

I tried building libcuckoo again and builders of all architectures did it successfully, but since nothing has changed in terms of source code, it seems to me that the problem still remains, although it is difficult to catch. You can find logs and artifacts of failed builds here https://gitlab.alpinelinux.org/grikir02/aports/-/pipelines/124124/builds because on the previous link the build log was overwritten by today's successful build.

reneengelhard commented 2 years ago

I changed build file to the version of the last commit and now results are https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/35004/pipelines Build is now successful for 32-bit architectures, but x86 failed at insert_expansion test. ppc64le and aarch64 failed this test last time too. I think it randomly segfaults no matter what architecture is being tested.

yeah, that seems to be a regression, though, even without changing the code. https://buildd.debian.org/status/package.php?p=libcuckoo&suite=sid built back then and passed the tests (log: https://buildd.debian.org/status/fetch.php?pkg=libcuckoo&arch=all&ver=0~git20210805-3&stamp=1640642581&raw=1) but that unchanged (as in apt-get source, build it) now gets the segfault, too

reneengelhard commented 2 years ago

https://ci.debian.net/packages/libc/libcuckoo/ and especially https://ci.debian.net/packages/libc/libcuckoo/unstable/amd64/ is probably better to look at. It seems that it started to fail for me too, then went away, and now is maybe back or maybe not. Looks like either something from the outside affecting it (compiler?) or just flakyness...

reneengelhard commented 2 years ago

ok, apparently it's flakiness. https://ci.debian.net/packages/libc/libcuckoo/unstable/amd64/ passed in an August 14 attempt (definitely with gcc 12); as does a manual build here.