[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 --- Comment #25 from Jean-Michaël Celerier --- My code is built with CMake with CMAKE_POSITION_INDEPENDENT_CODE set, which (I double checked) correctly adds -fPIC to the link line.
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 Jean-Michaël Celerier changed: What|Removed |Added CC||jeanmichael.celerier@gmail. ||com --- Comment #24 from Jean-Michaël Celerier --- Hello, I am still hitting this exact bug with GCC 11.1: calling std::cout in a library dlopen'd with RTLD_DEEPBIND causes a crash on sentry::sentry. I also found another report here : https://github.com/KhronosGroup/Vulkan-Loader/issues/433#issuecomment-658875808
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 maemarcus at gmail dot com changed: What|Removed |Added CC||maemarcus at gmail dot com --- Comment #23 from maemarcus at gmail dot com --- FWIW, I came across this issue with SEGFAULT in cerr on g++ 4.8.5. Interestingly, cout in the same time works fine. Got resolved either by removing RTLD_DEEPBIND, or by adding -static-libstdc++ to link line. Hint on adding -fPIC was not helpful, as it is already added everywhere. Program received signal SIGSEGV, Segmentation fault. 0x77b5af40 in std::ostream::sentry::sentry (this=0x7fffcf10, __os=...) at /build/gcc-4.8-Iyjgor/gcc-4.8-4.8.5/build/x86_64-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51 51if (__os.tie() && __os.good())
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 --- Comment #22 from Michael Truog mjtruog at fastmail dot ca 2013-02-05 23:47:08 UTC --- I believe this bug is resolved and was just a problem with my build setup. I am unable to confirm that this is the solution, just due to changes in versions and software, but I see no reason to not close this bug. Thank you for looking at the problem.
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-04 10:58:11 UTC --- (In reply to comment #19) (In reply to comment #16) I am using -fpic/-fPIC and in fact am using: // g++ -g -O0 main.cpp -ldl // g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp // g++ -shared -Wl,-export-dynamic -o library.so library.o What if you use -fPIC for the last step? (The manual does say it's necessary for predictable results when using -shared) As I said previously, the commands above should be using -fPIC when creating the .so, and when I tested it I found that using -fPIC for the first command, i.e. when compiling main.cpp, prevents the crash.
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 Yogesh Gaur gauryogesh.nsit at gmail dot com changed: What|Removed |Added CC||gauryogesh.nsit at gmail ||dot com --- Comment #20 from Yogesh Gaur gauryogesh.nsit at gmail dot com 2013-01-02 01:41:19 UTC --- Hello Jakub and Jason, Did we get any solution for this reported bugzilla. Actually I also have faced similar issue while loading my library using dlopen by passing RTLD_DEEPBIND flag. When I didn't pass this flag, no issues occurs and program run fine. I am using glibc-2.14. output with LD_DEBUG=all for both (crash and working) case : == WITH RTLD_DEEPBIND flag Linux# LD_DEBUG=all ./main_db 21 | grep _ZSt4cerr 424: symbol=_ZSt4cerr; lookup in file=./main_db [0] 424: binding file /lib/libstdc++.so.6 [0] to ./main_db [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 424: symbol=_ZSt4cerr; lookup in file=/lib/libdl.so.2 [0] 424: symbol=_ZSt4cerr; lookup in file=/lib/libstdc++.so.6 [0] 424: binding file ./main_db [0] to /lib/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 424: symbol=_ZSt4cerr; lookup in file=./library.so [0] 424: symbol=_ZSt4cerr; lookup in file=/lib/libstdc++.so.6 [0] 424: binding file ./library.so [0] to /lib/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] //-- This is problematic scenario here as binding of this symbol is done with libstdc++.so.6 == WITHOUT RTLD_DEEPBIND flag Linux# LD_DEBUG=all ./main_ndb 21 | grep _ZSt4cerr 427: symbol=_ZSt4cerr; lookup in file=./main_ndb [0] 427: binding file /lib/libstdc++.so.6 [0] to ./main_ndb [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 427: symbol=_ZSt4cerr; lookup in file=/lib/libdl.so.2 [0] 427: symbol=_ZSt4cerr; lookup in file=/lib/libstdc++.so.6 [0] 427: binding file ./main_ndb [0] to /lib/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 427: symbol=_ZSt4cerr; lookup in file=./main_ndb [0] 427: binding file ./library.so [0] to ./main_ndb [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] // -- Here proper binding happen and binding of library.so is done with main_ndb executable. == Please let me know if there is any solution for this long reported issue. I need to use RTLD_DEEPBIND flag.
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-29 23:50:51 UTC --- (In reply to comment #16) I am using -fpic/-fPIC and in fact am using: // g++ -g -O0 main.cpp -ldl // g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp // g++ -shared -Wl,-export-dynamic -o library.so library.o What if you use -fPIC for the last step? (The manual does say it's necessary for predictable results when using -shared) (In reply to comment #17) This is with using gcc for linking instead of g++. The main difference is that g++ automatically links to libstdc++, but if you use gcc and link to libstdc++ then you still get the same effect.
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679 Li Guanglei liguanglei at gmail dot com changed: What|Removed |Added CC||liguanglei at gmail dot com --- Comment #18 from Li Guanglei liguanglei at gmail dot com 2010-12-29 06:25:28 UTC --- Hi, I met the same bug on redhat 6.0 of x86_64. I use dlopen with -RTLD_DEEPBIND flag in my program, but it will crash once I start my program. But the this program runs well on SLES. And if I compiled using '-g' or '-O0', then it won't crash. Could someone help to look at this? It stops our product running on RH6/x86_64 liguangl:/u/liguangl/debugging uname -a Linux pexserv02.cn.ibm.com 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux liguangl:/u/liguangl/debugging cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.0 (Santiago) Here is the backtrace: (gdb) where #0 0x00362b4329a5 in raise () from /lib64/libc.so.6 #1 0x00362b434185 in abort () from /lib64/libc.so.6 #2 0x00362b46fd5b in __libc_message () from /lib64/libc.so.6 #3 0x00362b475676 in malloc_printerr () from /lib64/libc.so.6 #4 0x00363049ded1 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_M_mutate(unsigned long, unsigned long, unsigned long) () from /usr/lib64/libstdc++.so.6 #5 0x00363049df1c in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) () from /usr/lib64/libstdc++.so.6 #6 0x7f86d4aed228 in Log::init(char const*, char const*, int) () from /usr/lib64/libsci.so #7 0x7f86d4affa99 in Initializer::init() () from /usr/lib64/libsci.so #8 0x004188a7 in pm_contact (nprocs=value optimized out, n_masters=value optimized out, nodes=value optimized out) at /project/sprelbar/build/currentbar/src/ppe/poe/src/pm/poe/pm_contact.c:1337 #9 0x004200c1 in pm_mgr_init (nargs=value optimized out, argv=value optimized out, env=0x7fff857ee970) at /project/sprelbar/build/currentbar/src/ppe/poe/src/pm/poe/pm_manager.c:523 #10 0x00406ed0 in main (argc=1, argv=0x7fff857ee958, env=0x7fff857ee970) at /project/sprelbar/build/currentbar/src/ppe/poe/src/pm/poe/pm_poe.c:779
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #17 from mjtruog at fastmail dot ca 2010-03-07 17:53 --- I have found this doesn't fix the problem. It may fix the problem in the example, but not in all cases. I have a few new crash dumps: Core was generated by `_release/lib/cloud-0.0.9/priv/cloud_worker_port'. Program terminated with signal 6, Aborted. [New process 10276] [New process 10273] [New process 10277] #0 0x2b766a9a7015 in raise () from /lib/libc.so.6 (gdb) back #0 0x2b766a9a7015 in raise () from /lib/libc.so.6 #1 0x2b766a9a8b83 in abort () from /lib/libc.so.6 #2 0x2b766a9e80c8 in __libc_message () from /lib/libc.so.6 #3 0x2b766a9eda58 in malloc_printerr () from /lib/libc.so.6 #4 0x2b766a9f00a6 in free () from /lib/libc.so.6 #5 0x2b766ad8758e in std::string::_M_mutate (this=0x407f0ea0, __pos=0, __len1=0, __len2=32) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:231 #6 0x2b766ad875dc in std::string::_M_replace_safe (this=0x2821, __pos1=10276, __n1=6, __s=0x407f0741 243f6a8885a308d313198a2e03707344, __n2=47787595689792) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:662 #7 0x2aab2445 in bbp_pi (abortTask=value optimized out, digitIndex=value optimized out, digitStep=value optimized out, piSequence=value optimized out) at lib/cloud_job_tests/src/piqpr8_gmp.cpp:241 #8 0x2aab05db in do_work (abortta...@0x12387a2, workInstance=value optimized out, id=value optimized out, taskda...@0x1226ca0, taskDataSize=10, querieso...@0x407f0f70) at lib/cloud_job_tests/src/cloud_job_tests.cpp:145 #9 0x0041390d in WorkerController::WorkerExecution::ThreadPool::ThreadFunctionObject::operator() (this=0x407f1040, stopp...@0x12387a2, allocator=value optimized out) at lib/cloud_worker/src/worker_execution.cpp:501 warning: (Internal error: pc 0x419054 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x419054 in read in psymtab, but not in symtab.) #10 0x00419055 in boost::detail::thread_dataWorkerController::WorkerExecution::ThreadPool::ThreadObject::run (this=value optimized out) at lib/cloud_worker/src/worker_execution.cpp:236 warning: (Internal error: pc 0x419054 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x418fa0 in read in psymtab, but not in symtab.) #11 0x2b7669b05870 in thread_proxy () from /home/.../src/lib/boost/releases/boost_1_42_0_install/lib/libboost_thread.so.1.42.0 #12 0x2b766b27a3ea in start_thread () from /lib/libpthread.so.0 #13 0x2b766aa5acbd in clone () from /lib/libc.so.6 #14 0x in ?? () (gdb) I also continue to reproduce the same stderr problem (in debug mode): Core was generated by `_release/lib/cloud-0.0.9/priv/cloud_worker_port'. Program terminated with signal 11, Segmentation fault. [New process 11089] [New process 11090] #0 sentry (this=0x7fff4a32a8d0, __...@0x2abb61e70c20) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51 51if (__os.tie() __os.good()) (gdb) back #0 sentry (this=0x7fff4a32a8d0, __...@0x2abb61e70c20) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51 #1 0x2abb61c15048 in std::__ostream_insertchar, std::char_traitschar (__o...@0x2abb61e70c20, __s=value optimized out, __n=47) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h:80 #2 0x2abb61c1544f in operator std::char_traitschar ( __o...@0x2abb61e70c20, __s=0x2aab7360 cloud_job_tests global/static data initialize()) at /home/.../src/lib/g++/releases/gcc-4.4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/ostream:510 #3 0x2aab30d6 in initialize () at lib/cloud_job_tests/src/cloud_job_tests.cpp:100 #4 0x2aab7326 in __do_global_ctors_aux () from _release/lib/cloud-0.0.9/priv/work_types/libcloud_job_tests.so #5 0x2aab2423 in _init () from _release/lib/cloud-0.0.9/priv/work_types/libcloud_job_tests.so #6 0x2abb in ?? () #7 0x2abb60781a20 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #8 0x2abb6078649a in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #9 0x2abb60781676 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #10 0x2abb60785b2b in _dl_open () from /lib64/ld-linux-x86-64.so.2 #11 0x2abb611e8f5b in dlopen_doit () from /lib/libdl.so.2 #12 0x2abb60781676 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #13 0x2abb611e92cc in _dlerror_run () from /lib/libdl.so.2 #14 0x2abb611e8ec1 in dlopen@@GLIBC_2.2.5 () from /lib/libdl.so.2 #15 0x00425f17 in library (this=0x172a970, na...@0x7fff4a32ae60) at lib/cloud_worker/src/library.cpp:68 #16 0x00417cec in
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-29 10:08 --- Thanks Jakub, let's see what submitter has to say. Just want to add here that I'm building submitter' app **exactly** in the same way with g++ / icc, on the very same machine indeed, and in the former case the final executable crashes, in the latter it doesn't. But there are still many details I do not understand about this new feature, sorry if I'm saying something wrong. I suspect however that other lay users having icc installed could also report to us a puzzling behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #16 from mjtruog at fastmail dot ca 2010-01-29 17:04 --- I am using -fpic/-fPIC and in fact am using: // g++ -g -O0 main.cpp -ldl // g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp // g++ -shared -Wl,-export-dynamic -o library.so library.o I do want to use RTLD_DEEPBIND to keep the libraries in isolation as you mention, since I could have libraries that depend on different versions of GCC. I understand that it doesn't work right now with g++ linking, so I might try to switch to gcc linking. I just was concerned because it appeared to be connected to libstdc++, but I guess it is a g++ linking peculiarity. I don't think ignoring the RTLD_DEEPBIND feature in glibc would help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-28 08:03 --- If libstdc++ relies on ODR, then RTLD_DEEPBIND can break its assumptions, as then the same symbol which is defined in multiple shared libraries can resolve to different addresses (RTLD_DEEPBIND means first the dlopened library and its dependencies, and only after it the global search scope, will be searched). STB_GNU_UNIQUE object ought to cure it, though it is only in 4.5 (and 4.4-RH) gcc and sufficiently new binutils and glibc are needed for it too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-28 09:50 --- Many thanks Jakub. I have to give this issue much more thought. For the time being I'm going to add Jason in CC in case he wants to suggest something in particular, I see he was involved in the STB_GNU_UNIQUE idea quite directly. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-28 20:01 --- The issue Jakub describes is indeed the motivation for STB_GNU_UNIQUE. But I don't know why RTLD_DEEPBIND would cause trouble when the library is only loaded once. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-28 22:07 --- The theoretical example is libstdc++ defining some object where things misbehave if it is not the only one (say foo) and some other library has that object as well. When that other library isn't an direct or indirect dependency of the executable, but libstdc++ is, in all libraries loaded before start of the program foo resolves to the libstdc++ copy. When you dlopen RTLD_DEEPBIND this other library, foo in it and all its dependencies will resolve to the other library, as it comes earlier in the search scope, before global scope. I guess LD_DEBUG=all could shed some light into what exactly is going on, it could be the empty string, or something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-28 22:35 --- Jakub, Jason, thanks for the additional info, hopefully we can make progress on this issue. By the way, I'm not sure if you noticed that we have an actual reproducer in Comment #2, is it consistent with your theoretical analysis? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #11 from jakub at gcc dot gnu dot org 2010-01-28 22:49 --- LD_DEBUG=all ./main 21 | grep _ZSt4cerr 12758: symbol=_ZSt4cerr; lookup in file=./main [0] 12758: binding file /usr/lib64/libstdc++.so.6 [0] to ./main [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 12758: symbol=_ZSt4cerr; lookup in file=/lib64/libdl.so.2 [0] 12758: symbol=_ZSt4cerr; lookup in file=/usr/lib64/libstdc++.so.6 [0] 12758: binding file ./main [0] to /usr/lib64/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 12758: symbol=_ZSt4cerr; lookup in file=./library.so [0] 12758: symbol=_ZSt4cerr; lookup in file=/usr/lib64/libstdc++.so.6 [0] 12758: binding file ./library.so [0] to /usr/lib64/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] The first lookup is for std::cerr relocations in libstdc++, the second one is just to find out what should be the std::cerr COPY relocation in main be initialized for. Thus, the executable uses std::cerr inside of main's .bss. But during RTLD_DEEPBIND first library.so and its dependencies are searched, so the copy in libstdc++.so.6 (which hasn't been initialized at runtime) is used. Note that std::cerr isn't STB_GNU_UNIQUE, so this crashes even on Fedora 12. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-28 22:59 --- Good. Now, if I can have a little bit more of your time, I have two main curiosities: can you guess why the same 4.4.x *.so + headers don't lead to a crash with ICC? Then, we should of course come to a possible fix: the idea would be checking at configure time that the underlying glibc is recent enough (is 10.1 ok?) and then marking STB_GNU_UNIQUE some selected exported symbols? The static allocated ones? I'm guessing a bit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-29 00:46 --- This is the LD_DEBUG output for Icc 11.1, thus no crash. 17439: symbol=_ZSt4cerr; lookup in file=./a.out [0] 17439: binding file /usr/lib64/libstdc++.so.6 [0] to ./a.out [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/libdl.so.2 [0] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/libm.so.6 [0] 17439: symbol=_ZSt4cerr; lookup in file=/usr/lib64/libstdc++.so.6 [0] 17439: binding file ./a.out [0] to /usr/lib64/libstdc++.so.6 [0]: normal symbol `_ZSt4cerr' [GLIBCXX_3.4] 17439: symbol=_ZSt4cerr; lookup in file=./library.so [0] 17439: symbol=_ZSt4cerr; lookup in file=/opt/intel/Compiler/11.1/064/lib/intel64/libimf.so [0] 17439: symbol=_ZSt4cerr; lookup in file=/opt/intel/Compiler/11.1/064/lib/intel64/libsvml.so [0] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/libm.so.6 [0] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/libgcc_s.so.1 [0] 17439: symbol=_ZSt4cerr; lookup in file=/opt/intel/Compiler/11.1/064/lib/intel64/libintlc.so.5 [0] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/libc.so.6 [0] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/libdl.so.2 [0] 17439: symbol=_ZSt4cerr; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 17439: symbol=_ZSt4cerr; lookup in file=./a.out [0] 17439: binding file ./library.so [0] to ./a.out [0]: normal symbol `_ZSt4cerr' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #14 from jakub at gcc dot gnu dot org 2010-01-29 07:52 --- Clearly this works with icc, because library.so isn't linked against libstdc++.so. I guess if you link the library with gcc instead of g++, it will work too. Any reason why you need to use RTLD_DEEPBIND? AFAIK it has been mainly to support libraries linked against a different version of libstdc++ from the rest of the app (say the program and all its libraries linked against GCC 3.2/3.3 libstdc++, while some library it dlopens linked against GCC 3.4+ libstdc++. I'd say there is nothing that should be done on the libstdc++ side, this can happen with any kinds of symbols in any library. What can help is compile the program with -fpic/-fPIC, then it won't have copy relocation and thus this problem won't exist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-28 03:10 --- Jakub, any idea? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #4 from mjtruog at fastmail dot ca 2010-01-22 07:10 --- I can help try to determine the problem if you want since it seems everyone is either busy, doesn't necessarily care right now, or both. However, if someone could provide any hints as to what RTLD_DEEPBIND might be doing to libstdc++ internals that is atypical behavior, it would be helpful. I just suggested that it might be a design problem since it seems like the problem might have a broad scope. I don't wish to suggest that libstdc++ is directly responsible for no reason. I was expecting that there was some strange compiler specific linking going on somewhere but have not set out to try to find anything strange like that since I assumed other people would have a better idea of what might be causing the problem. The problem with RTLD_DEEPBIND might be a new one since it appeared in glibc 2.3.4. While the option is not critical, it seems helpful for keeping dynamic libraries in isolation if it is an N-to-1 relationship where many dynamic libraries are used for a single executable, at runtime based on runtime events. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-10 10:42 --- At the very minimum we need a small reproducer. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #2 from mjtruog at fastmail dot ca 2010-01-10 18:16 ---
I have been trying to make a simple test case for the ostringstream problem but
have not yet found one. However, I have been able to make a test case for the
crash when using std::cerr. The problems are probably related in some way, but
the std::ostringstream one I found may be harder to recreate. I have the files
to replicate the std::cerr crash scenario below:
main.cpp:
#include dlfcn.h
#include iostream
// compile with: g++ -g -O0 main.cpp -ldl
int main()
{
char const * const library_name = ./library.so;
void * handle = dlopen(library_name, RTLD_NOW | RTLD_LOCAL |
RTLD_DEEPBIND);
char const * const dlopen_error = dlerror();
if (! handle)
{
std::cerr dlopen error: dlopen_error std::endl;
return 1;
}
typedef void (*library_function_type)();
void * function = dlsym(handle, library_function);
char const * const dlsym_error = dlerror();
if (dlsym_error)
{
std::cerr dlsym error: dlsym_error std::endl;
dlclose(handle);
return 1;
}
reinterpret_castlibrary_function_type(function)();
dlclose(handle);
return 0;
}
library1.cpp:
#include sstream
#include iostream
// example of SEGFAULT when writing to std::cerr
// compile with:
// g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp
// g++ -shared -Wl,-export-dynamic -o library.so library.o
extern C
{
void library_function()
{
std::clog std::cerr will segfault std::endl;
std::cerr crash me;
}
}
--
mjtruog at fastmail dot ca changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-10 19:18 --- Well, these are two interesting data points: 1- The crash definitely is not new, happens also with 4.2.4; 2- The same 4.4.x library, but ICC as C++ compiler, doesn't crash, maybe it's a random behavior, sure, but I would be cautious with design problems. Maybe Jakub can spot something... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679
