Description of problem: If you use the container library with the address sanitizer enabled, it crashes. The problem is that abseil-cpp detects whether the sanitizer is enabled or not, and changes its behavior accordingly. See the SwisstableGenerationsEnabled() function. During abseil-cpp build time, it detects that the sanitizer is disabled, and bakes that into the shared object. During my application's build time, it detects that the sanitizer is enabled, and bakes that into the generated code. The different conclusions clash, and the application crashes. Version-Release number of selected component (if applicable): abseil-cpp-20240116.2-1.fc40.x86_64 How reproducible: Always. Steps to Reproduce: 1. If there is interest in solving this, I can provide a reproducer. Actual results: Crash on null pointer dereference │ 871 class HashSetIteratorGenerationInfoEnabled { │ │ 872 public: │ │ 873 HashSetIteratorGenerationInfoEnabled() = default; │ │ 874 explicit HashSetIteratorGenerationInfoEnabled( │ │ 875 const GenerationType* generation_ptr) │ │ > 876 : generation_ptr_(generation_ptr), generation_(*generation_ptr) {} │ │ 87 Expected results: No crash Additional info: https://github.com/abseil/abseil-cpp/issues/1524 The problem can be fixed in two ways: - have Fedora package a sanitizer-enabled version of the libaries - have the user build abseil from source, with the sanitizer flags inherited from their project
This is inconvenient for people developing against the Fedora package, but I’m not sure what alternatives there are. We don’t want to enable the sanitizers in the system-wide abseil libraries: they are not intended for production use, for performance and other reasons. I don’t know a straightforward way to ship a parallel-installable set of abseil libraries with alternative build options that people could choose to use instead. Besides, there are many combinations of sanitizers that could possibly be enabled or disabled (ABSL_HAVE_THREAD_SANITIZER, ABSL_HAVE_ADDRESS_SANITIZER, ABSL_HAVE_DATAFLOW_SANITIZER, ABSL_HAVE_MEMORY_SANITIZER, ABSL_HAVE_HWADDRESS_SANITIZER…). Even a conflicting version of the package with one or more sanitizers has this problem. Even if such an approach could be made to work, it would require a lot of boilerplate and would make the package very “weird” and difficult compared to other Fedora packages. In general, I think it’s reasonable to expect that people developing against abseil-cpp need to build it from source to use particular options like sanitizers. Upstream tries to push people this way anyway. It should still be possible to use the packaged abseil-cpp in production. Note that people are even having trouble with differences in whether NDEBUG is defined: https://github.com/abseil/abseil-cpp/issues/1624 If you think I’ve missed something that can reasonably be done to make the package more useful for all users, or if Rich has something to add, I’m happy to listen and consider.
I agree it looks hard for Fedora to provide a good response here. We can say that abseil-cpp is intended to satisfy Fedora's own dependencies and that users who need fine-grained control over abseil build flags must build it from source.
(In reply to Avi Kivity from comment #2) > I agree it looks hard for Fedora to provide a good response here. We can say > that abseil-cpp is intended to satisfy Fedora's own dependencies and that > users who need fine-grained control over abseil build flags must build it > from source. Ok, thanks for the follow-up. I’m going to close this as NOTABUG, but please reopen it if you realize there’s something we can reasonably do to make this better for users.