Repository: abseil/abseil-cpp

Issue #1133: Symbolize.SymbolizeWithMultipleMaps fails in absl_symbolize_test on s390x with LTO
Created: 2022-03-15T16:29:20Z
Describe the bug
In the Fedora Linux distribution package for abseil-cpp, we find that Symbolize.SymbolizeWithMultipleMaps in absl_symbolize_test fails on the s390x architecture. When the test fails, a message like
/builddir/build/BUILD/abseil-cpp-20210324.2/absl/debugging/symbolize_test.cc:315: Failure
Expected equality of these values:
  "kPadding1"
  buf
    Which is: ""
/builddir/build/BUILD/abseil-cpp-20210324.2/absl/debugging/symbolize_test.cc:349: Failure
Expected equality of these values:
  expected[i]
    Which is: "kPadding1"
  buf
    Which is: ""
/builddir/build/BUILD/abseil-cpp-20210324.2/absl/debugging/symbolize_test.cc:349: Failure
Expected equality of these values:
  expected[i]
    Which is: "kPadding1"
  buf
    Which is: ""

is printed.
When LTO is disabled in the build, the test does not fail.
Steps to reproduce the bug
The error can be observed in the RPM build infrastructure for Fedora Linux, but there is nothing particularly special about how we are building the library, and there are no significant downstream patches involved. I expect that this error can probably be reproduced on any s390x system when combined with LTO.
What version of Abseil are you using?
20111102.0
What operating system and version are you using
Fedora Linux Rawhide/37 (development version)
What compiler and version are you using?
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.0.1-20220308/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220308 (Red Hat 12.0.1-0) (GCC) 

What build system are you using?
cmake version 3.23.0-rc2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Additional context
We are using https://github.com/abseil/abseil-cpp/archive/20111102.0/abseil-cpp-20111102.0.tar.gz with:

CMake build system (using ninja backend)
System copies of gtest/gmock 1.11.0
A small patch for #1063
System compiler GCC 12.0.1

While I don’t have convenient interactive access to real s390x hardware, I can easily test patches or try experiments on real hardware by submitting “scratch” RPM builds.
I have attached a complete failing build log including compiler flags.
No other architectures (of x86_64, i686, aarch64, and ppc64le) are affected.

Duplicate issue #1132: CordzInfoStatisticsTest.ThreadSafety flaky failure on ppc64le
Created: 2022-03-14T21:34:31Z
Describe the bug
In the Fedora Linux distribution package for abseil-cpp, since updating to 20211102.0 in the development version of the distribution, we see frequent flaky failures of CordzInfoStatisticsTest.ThreadSafety in absl_cordz_info_statistics_test on the ppc64le architecture. When the test fails, a message like [mutex.cc : 1682] RAW: Mutex unlocked when destroyed or not locked: v=0x0 is printed.
Steps to reproduce the bug
The error can be observed in the RPM build infrastructure for Fedora Linux, but there is nothing particularly special about how we are building the library, and there are no significant downstream patches involved. I expect that this error can probably be reproduced on any ppc64le system.
What version of Abseil are you using?
20111102.0
What operating system and version are you using
Fedora Linux Rawhide/37 (development version)
What compiler and version are you using?
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.0.1-20220308/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220308 (Red Hat 12.0.1-0) (GCC) 

What build system are you using?
cmake version 3.23.0-rc2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Additional context
We are using https://github.com/abseil/abseil-cpp/archive/20111102.0/abseil-cpp-20111102.0.tar.gz with:

CMake build system (using ninja backend)
System copies of gtest/gmock 1.11.0
A small patch for #1063
System compiler GCC 12.0.1

While I don’t have convenient interactive access to real PowerPC hardware, I can easily test patches or try experiments on real hardware by submitting “scratch” RPM builds.
I have attached a complete build log from a failing build.
I just did a trial of five builds, in which three succeeded and two failed. Assuming builds succeed or fail independently, and using the Clopper-Pearson method, a 90% confidence interval for the failure rate for this test is approximately 8–81%. This is good enough to say that the test fails “frequently.”
No other architectures (of x86_64, i686, aarch64, and s390x) are affected.

Closing comment (2022-03-15T18:05:48Z): It looks like, similar to #1133, this can be worked around by disabling LTO.
EDIT: I take it back. The problem is still present with LTO. It might be rarer, or I might have just gotten (un)lucky with my first batch of tests.