Ryan Hill <dirtyepic@xxxxxxxxxx> writes: > I don't have a copy of mainline installed, but I do see the error with 4.6 > branch HEAD. I know at least Debian and Arch have the same problem. > > Playing around with the testcase it looks like it works if a C++ module is > the first to be dlclosed, regardless of the number or order of C/C++ > modules unloaded afterwards, and likewise fails if a C module is closed first. OK, I managed to recreate the problem with current mainline. I had to use an explicit -lstdc++ when linking test2.so. That gives test2.so a DT_NEEDED entry for libstdc++.so. When the test2.so is dlopen'ed, it calls the DT_INIT_ARRAY entries for libstdc++.so. This creates the variables generic_category_instance and system_category_instace defined in libstdc++-v3/src/system_error.cc. It also passes the destructor for those variables to __cxa_atexit, along with the DSO handle for libstdc++.so. Later, when test1.so and test2.so are dlclose'd, __cxa_finalize is called with DSO handles corresponding to test1.so and test2.so, but __cxa_finalize is never called with the DSO handle for libstdc++.so. So the destructors that libstdc++.so passed to __cxa_atexit stick around. When the program exits, the exit function calls all the remaining finalizers. At this point the destructor runs, but libstdc++.so has been removed from the symbol map, so the symbol resolution error occurs. It looks like the libstdc++.so destructor is not being run because it has a reloc against a STB_GNU_UNIQUE symbol. I wrote a standalone test case, attached. This test case recreates the problem on Ubuntu Lucid running eglibc 2.11.1-0ubuntu7.8. However, the test case passes on Fedora 14 running glibc 2.13. So it appears that this bug has been fixed in upstream glibc. I'm not sure which change fixes the bug, but it may be the patch for http://sourceware.org/bugzilla/show_bug.cgi?id=12510 or http://sourceware.org/bugzilla/show_bug.cgi?id=12511 . Ian
Attachment:
bug.tar.bz2
Description: test
