Hi Adam, On 18/12/20 at 08:46 +0100, Adam Borowski wrote: > Control: tags -1 + moreinfo unreproducible > > Hi Lucas! > > > On Wed, Dec 09, 2020 at 09:39:08AM +0100, Lucas Nussbaum wrote: > > > Source: memkind > > > > During a rebuild of all packages in sid, your package failed to build > > > on ppc64el. At the same time, it did not fail on amd64. > > > > > I'm marking this bug as severity:serious since your package currently has > > > ppc64el binary packages in unstable (so this is a regression). > > > > > [ RUN ] GetArenaTest.test_TC_MEMKIND_ThreadHash > > > > test/get_arena_test.cpp:67: Failure > > > > Expected: (max_collisions) <= (collisions_limit), actual: 10 vs 5 > > > > [ FAILED ] GetArenaTest.test_TC_MEMKIND_ThreadHash (184 ms) > > Ping: > > Is that fail reproducible for you? I have a possible fix, but have no way > > of verifying it -- the package builds successfully on all machines I have > > access to, and did build fine on buildds (no major changes to toolchain > > since then). > > The underlying code uses an assumption on the internal working for glibc, > that might possibly be invalid in some cases. Even if it happens to be > wrong, correctness is not violated, there's just a performance loss. > > The test that fails could thus be removed -- however, I'd like to know how > it did fail in the first place. No matter how I tried, I did not manage to > reproduce the failure. > > There are also multiple ways to improve this hash (an explicit mapping, a > "random" hash, etc) but as this code is used in large performance-critical > parts, I'd prefer to first understand.
Sorry for the late reply. This machine has SMT with 10 threads per core (so a total of 160 "cpus" in /proc/cpuinfo), and this proved to cause some issues. I tried again building 1.10.1-1, and: - the build succeeded with SMT off - the build failed again with SMT on Lucas
