-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix multi construct of g_gmock_implicit_sequence #4536
base: main
Are you sure you want to change the base?
Conversation
…linked to many shared library Signed-off-by: arvin <icemanpeng@foxmail.com>
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Hi! I'm a little bit confused, how does moving the global into a function avoid the problem of multiple constructions? Wouldn't each shared library still get its own copy of that global? Perhaps the constructions would be avoided if the function isn't called from both libraries, but if/when it is, you should still get two constructions, no? It seems to me that what you may really want is for |
FWIW I am seeing this same issue when compiling against the googletest source, so I don't think the shared / static conversation has anything to do with it. Having a hard time reproducing an MRE but hope to be able to craft one soon. Here's some backtraces from gdb to illustrate - the first and the last breakpoints are from an object at the same memory address, trying to delete the same pthread key twice and causing UB
|
Not sure if I understand what you're doing correctly, but compiling each of 2 libraries against the source of the same 3rd is equivalent to static linking as far as this problem is concerned, and hence (as expected in my last comment) you'd expect this to come up there too. But yeah, an MRE would be helpful whenever you have one. |
Ah OK - thanks for that info. I am using the Meson wrap for googletest which just provides the source file to other compilation targets. I'll see if I can work around that and get a shared library compiled instead, or try to get this down to something more debuggable. Thanks for the quick reply |
To be clear though - I don't have the same linkage situation as the OP, just am getting the same error. My linker command looks something like: c++ -o driver/sqlite/adbc-driver-sqlite-test
subprojects_googletest-1.14.0_googletest_src_gtest-all.cc.o
subprojects_googletest-1.14.0_googlemock_src_gmock-all.cc.o
subprojects_googletest-1.14.0_googlemock_src_gmock_main.cc.o
... |
While not quite an MRE you can reasonably see this if you work with this project: https://github.com/WillAyd/arrow-adbc/tree/aeccd962d530a61f31909c083a05412110e77f2b With the following compilation steps: cd c
meson setup builddir -Dtests=true -Dsqlite=true && cd builddir
meson compile Then either |
Thank you, but I suspect we won't have the bandwidth to to track down such an issue in a massive project like this. I'd really need something minimal that I can understand by eyeballing. |
Totally understood - no expectations for you to go through those steps. Just providing as reference for now |
When libgmock.a is linked to a multitude of shared libraries, g_gmock_implicit_sequence will be constructed multiple times. For instance:
When BinaryC executes,
g_gmock_implicit_sequence
is constructed and destroyed twice, and the private memberconst pthread_key_t key_
inThreadLocal
will be called inpthread_key_delete
twice, resulting in the failure ofGTEST_CHECK_POSIX_SUCCESS_(pthread_key_delete(key_))
.Furthermore,
ThreadLocal<Sequence*> g_gmock_implicit_sequence
is not trivially destructible, which violates the google code style.