Comments (17)
@derekmauro @dvyukov, could you comment about the (un-)inlining of the Mutex destructor, or alternatively, chime in on the linked grpc issue if their usage of the Mutex is somehow not supported?
from abseil-cpp.
CC @dvyukov as the author of f3760b4.
Relevant context is also that we're using shared builds of abseil.
from abseil-cpp.
I ended up building a version of abseil (published in a separate channel) with the following patch:
diff --git a/absl/synchronization/mutex.cc b/absl/synchronization/mutex.cc
index cb3c7e74..76d561df 100644
--- a/absl/synchronization/mutex.cc
+++ b/absl/synchronization/mutex.cc
@@ -731,12 +731,10 @@ static unsigned TsanFlags(Mutex::MuHow how) {
}
#endif
-#if defined(__APPLE__) || defined(ABSL_BUILD_DLL)
// When building a dll symbol export lists may reference the destructor
// and want it to be an exported symbol rather than an inline function.
// Some apple builds also do dynamic library build but don't say it explicitly.
Mutex::~Mutex() { Dtor(); }
-#endif
#if !defined(NDEBUG) || defined(ABSL_HAVE_THREAD_SANITIZER)
void Mutex::Dtor() {
diff --git a/absl/synchronization/mutex.h b/absl/synchronization/mutex.h
index d53a22bb..2cd5a1e4 100644
--- a/absl/synchronization/mutex.h
+++ b/absl/synchronization/mutex.h
@@ -1064,11 +1064,6 @@ inline Mutex::Mutex() : mu_(0) {
inline constexpr Mutex::Mutex(absl::ConstInitType) : mu_(0) {}
-#if !defined(__APPLE__) && !defined(ABSL_BUILD_DLL)
-ABSL_ATTRIBUTE_ALWAYS_INLINE
-inline Mutex::~Mutex() { Dtor(); }
-#endif
-
#if defined(NDEBUG) && !defined(ABSL_HAVE_THREAD_SANITIZER)
// Use default (empty) destructor in release build for performance reasons.
// We need to mark both Dtor and ~Mutex as always inline for inconsistent
With this, the grpc example compiles again.
from abseil-cpp.
Could this simply be a case of the shared library case on linux not being covered correctly?
from abseil-cpp.
Do you use bazel or cmake build?
I am not an expert on all open-source absl build modes.
Is it possible to add a test for this?
I see this code does something similar:
abseil-cpp/absl/base/internal/thread_identity.h
Lines 249 to 252 in 14b8a4e
and it also checks ABSL_CONSUME_DLL. Should we check ABSL_CONSUME_DLL here as well? Though, not sure how this is related to consuming dll's.
I see that this:
abseil-cpp/absl/copts/AbseilConfigureCopts.cmake
Lines 6 to 9 in 14b8a4e
exports ABSL_BUILD_DLL only for Windows (MSVC).
Is there a macro for BUILD_SHARED_LIBS mode? Perhaps we should check that macro?
from abseil-cpp.
Hey @dvyukov, thanks for the response. We're using CMake to build, which correctly sets ABSL_BUILD_DLL
on windows (and ABSL_CONSUME_DLL
gets correspondingly set when building against shared abseil).
My understanding is that this mechanism originally was intended (only?) for __declspec(dllexport)
(resp. dllimport
), which is necessary to make shared builds work on windows at all.
Now the problem only appears on Linux, where usually, ABSL_BUILD_DLL
should not be a thing, according to my understanding. But if that's the preferred solution, I'm happy to set that symbol also on Linux while building.
It would be functionally equivalent to the patch I posted above, which I already tested successfully.
from abseil-cpp.
It would be functionally equivalent to the patch I posted above, which I already tested successfully.
If I read your first patch correctly, it effectively undoes the optimization, so it's not good.
I am not expect on absl build modes and macros, especially used in open-source. So I will defer this to absl maintainers. @derekmauro do you know who can say what's the right fix for this?
from abseil-cpp.
I'll take a look when I can. Please be patient.
from abseil-cpp.
It would be functionally equivalent to the patch I posted above, which I already tested successfully.
If I read your first patch correctly, it effectively undoes the optimization, so it's not good.
My intention was not to suggest that the patch should be merged, what I meant was that for our specific scenario (builds against a shared abseil) the removal of the #if
had the same effect as defining ABSL_BUILD_DLL
.
I'll take a look when I can. Please be patient.
I hope that a first ping after a week is not considered excessive. 😅
It is blocking a lot of work in our distribution though, so I was mainly looking for overall direction, rather than a fix. For now, I don't even know if this is an issue in abseil or in grpc, but I'm assuming that lots of places implicitly use the Mutex, and since all our builds are shared, I expect this to be too much to fix everywhere on the side of abseil-consumers (though perhaps I'm wrong though and it's grpc-specific after all!).
The upshot is that I'm looking towards just uninlining the Dtor (in our distribution) for 20240116.x, which should at least unblock us for now, and we can then reconsider for the summer release. If you think I should hold off on that for ${reason}
, please let me know.
from abseil-cpp.
I haven't tried this, but I ran the build "in my head" (which tends to be unreliable). I think it is likely caused by mixing an installed absl library built with -DNDEBUG
with a gRPC library that includes absl headers that is not being built with -DNDEBUG
. If this is the case, it is something I've been begging people not to do.
This is one of those build modes I would like to say is not supported, as I regularly have to tell people when they only instrument half of their builds with sanitizers, but the fact of the matter is that with -DNDEBUG
, people get away with doing this 99.9% of the time.
One option which I really don't like is to patch this for open-source users, but keep @dvyukov's optimization for internal Google users only. This would be an annoying maintainability problem. I'll have to test it to see how bad it actually looks.
from abseil-cpp.
Thank you for the response!
This is an interesting case, because we do set -DNDEBUG
for our release builds, but the failure occurred while naïvely building examples/cpp/helloworld
from grpc, which doesn't set that symbol.
It's surprising to me that the logic here is
Lines 91 to 100 in 2f9e432
rather than, say
#ifdef(DEBUG)
<debug-case>
#else
<nodebug-case>
#fi
The latter would not open up that footgun of a vanilla build (no options) having a different ABI than one with -NDEBUG
.
If this is the case, it is something I've been begging people not to do.
I understand, though the realities of a distribution are that we have to use pre-built artefacts. If that means that we have to put NDEBUG
in the library interface, we can do that
from abseil-cpp.
This is an interesting case, because we do set
-DNDEBUG
for our release builds, but the failure occurred while naïvely buildingexamples/cpp/helloworld
from grpc, which doesn't set that symbol.
OK, I misdiagnosed that (probably trying to fit your analysis subconsciously) -- the compiler setup is the same in all cases, so we do set -DNDEBUG
even for that grpc example. I've double-checked this in conda-forge/grpc-cpp-feedstock#357.
from abseil-cpp.
OK, I misdiagnosed that [...]
Yet another update: while our compiler setup is the same (CPPFLAGS
contains -DNDEBUG
, CXXFLAGS
does not), it seems that abseil and grpc differ in how they pick this up - abseil consequently does build with -DNDEBUG
, while grpc (or at least the example) doesn't. Adding -DNDEBUG
to the CXXFLAGS
for the grpc example does make it work again, validating your analysis.
from abseil-cpp.
I have also an issue with the inlined desctructor, but on windows when building static libs of abseil.
When I build ortools v9.9 which uses abseil 202401 version of abseil, I get multiply defined symbols for Mutex::Dtor().
Ortools is quite big and it uses abseil, but also Protobuf as dependencies. Up to now I did not test it with the (rollback-)patch, but this seems likely a fix for the issue.
from abseil-cpp.
Does this build include inconsistent NDEBUG defines (as @derekmauro mentioned here #1624 (comment))?
from abseil-cpp.
Not that I am aware of. The ortools cmake machinery is quite complex so I cannot easily verify that, maybe I find the time to dig into that more. Another possibility could be a wrongly set or logically incorrect usage of the flag BUILD_ABSL_DLL.
from abseil-cpp.
I'd like to add, for anyone coming across similar problems, that not defining the NDEBUG macro in your Release build will cause very cryptic errors at the linker stage; in my case, a dependency on grpc (and therefore protobuf and abseil) managed via vcpkg in an MSbuild project on Windows produced ODR Violation linker errors exactly in Mutex::Dtor. It wasn't until I randomly stumbled across this exact thread after hours of increasingly desperate internet searches that I noticed the missing NDEBUG definition on my command line. Obvious error in retrospect, but tracing that down backwards from the link stage to the preprocessor was pretty nightmarish. It feels like this should be mentioned in documentation somewhere, so other developers don't have to go through that ordeal. Maybe this comment will help someone directly or serve as a starting point for this information to be more visible to library users.
from abseil-cpp.
Related Issues (20)
- [Bug]: Unusable for installable projects whose other dependencies also define a `check` target HOT 3
- Resolving linking order is a nightmare on alpine HOT 4
- mismatched types ‘absl::lts_2020_09_23::FormatSpec<Args ...>’ and ‘const char [34]’ HOT 1
- [Bug]: Compilation error on mac: xcode command line interface 15.3
- [Bug]: Make absl::InitializeLog safe to be called multiple times
- [Bug]: Cant compile app on windows with MinGW that use Absl::Flags target.
- [Bug]: Can't build on macOS: `'linux/futex.h' file not found`
- [Bug]: new flat_hash_map to empty string could cause memory corruption in c++20 HOT 7
- GCC 14: abseil-src/absl/numeric/internal/bits.h:309:24: error: '__builtin_ctzs' needs isa option -mbmi HOT 3
- [Bug]: arm_neon.h inclusion causing issues HOT 2
- [CMake]: Could not find a configuration file for package "absl" that is compatible with requested version ""
- [Bug]: clang-analyzer-optin.core.EnumCastOutOfRange for static_cast<ctrl_t>(0) HOT 2
- [Bug]: undefined reference to `absl::lts_20240116::raw_log_internal::internal_log_function[abi:cxx11]' HOT 1
- [Bug]: algorithm\container.h is missing random header and causing compilation error when building protobuf in VS2022 HOT 1
- [Bug]: ASAN use-after-poison in TimeZoneInfo HOT 3
- [Bug]: SEGV with btree_set::equal_range HOT 2
- [Bug]: build failure on redhat/ubi8
- [Bug]: Compilation error for filesystem HOT 1
- [Bug]: raw hash set test crash on centos7 HOT 1
- [Bug]: NegativeNaN test fails on riscv64 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from abseil-cpp.