https://bugzilla.novell.com/show_bug.cgi?id=645652 https://bugzilla.novell.com/show_bug.cgi?id=645652#c0 Summary: Destructors of static variables not called during dlclose, ... sometimes ... Classification: openSUSE Product: openSUSE 11.3 Version: Final Platform: i686 OS/Version: openSUSE 11.3 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: pth@novell.com ReportedBy: christoph.pesch@siemens.com QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100914 SUSE/3.6.10-0.3.1 Firefox/3.6.10 Under unclear conditions, destructors of static variables in a shared object loaded with dlopen() are not called during dlclose() but later at program termination. The behavior toggles depending on whether std::vectorstd::string or std::dequestd::string is used, the application is linked to boost_regex or not, dlopen() was invoked with RTLD_LAZY or RTLD_NOW, etc. Sometimes you need RTLD_NOW to see the problem, sometimes you can see it with RTLD_LAZY, too. I am not sure whether this problem is related to Bug 622977. The problem is not present in SUSE 10.2. It is present in openSUSE 11.3 with an older version of gcc (4.1.2) that I installed temporarily to investigate this problem. Therefore I guess it is a problem with the dynamic linker or libc. I wrote a small example which demonstrates the behavior (see attachment). You will need gcc, make and the boost libraries to reproduce it. The example includes source for a shared object which shows the expected behavior and for another shared object which shows the bug. The shared objects include a static variable which prints and flushes some output in the constructor and in the destructor. The main program prints some output, calls dlopen, prints some other output, calls dlclose and prints another output before it terminates. The expected order of output is 1. main (before dlopen), 2. Constructor (during dlopen) 3. main (after dlopen, before dlclose), 4. Destructor (during dlclose), 5. main (after dlclose). It works as expected in the first example. The second example adds an (unused) function that adds an element to a std::vectorstd::string and links boost_regex to the shared object. Now the order of output is 1. main (before dlopen), 2. Constructor (during dlopen) 3. main (after dlopen, before dlclose), 4. main (after dlclose), 5. Destructor (during program termination). The destructor is called too late. This behavior toggles if boost_regex is not linked to the shared object. It toggles again if the dlopen uses option RTLD_LAZY instead of RTLD_NOW. But I had other, more complicated examples, where I could see the same problem with RTLD_LAZY, too. Other examples (too complicated to include here) showed the problem with other boost libraries. Strange! Reproducible: Always Steps to Reproduce: 1. tar xvf dlclose_problem.tar 2. cd dlclose_problem 3. make 4. ./load_shared_object ./libshared_object1.so 5. ./load_shared_object ./libshared_object2.so Actual Results: pesch@kstbu027[~/src/c++/test/dlclose_problem]239: ./load_shared_object /libshared_object1.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... in ~SomeOutput() after dlclose. pesch@kstbu027[~/src/c++/test/dlclose_problem]240: ./load_shared_object /libshared_object2.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... after dlclose. in ~SomeOutput() Expected Results: pesch@kstbu027[~/src/c++/test/dlclose_problem]239: ./load_shared_object /libshared_object1.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... in ~SomeOutput() after dlclose. pesch@kstbu027[~/src/c++/test/dlclose_problem]240: ./load_shared_object /libshared_object2.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... in ~SomeOutput() after dlclose. pesch@kstbu027[~/src/c++/test/dlclose_problem]326: which gcc /usr/bin/gcc pesch@kstbu027[~/src/c++/test/dlclose_problem]327: gcc --version gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. pesch@kstbu027[~/src/c++/test/dlclose_problem]340: ls -latr /lib/ld-2.11.2.so -rwxr-xr-x 1 root root 143978 2010-07-19 12:10 /lib/ld-2.11.2.so pesch@kstbu027[~/src/c++/test/dlclose_problem]341: ldd libshared_object2.so linux-gate.so.1 => (0xffffe000) libboost_regex.so.1.42.0 => /usr/lib/libboost_regex.so.1.42.0 (0xb75ed000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb74fd000) libm.so.6 => /lib/libm.so.6 (0xb74d3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb74b5000) libc.so.6 => /lib/libc.so.6 (0xb7349000) libicui18n.so.42 => /usr/lib/libicui18n.so.42 (0xb71a0000) libicuuc.so.42 => /usr/lib/libicuuc.so.42 (0xb7053000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7038000) /lib/ld-linux.so.2 (0xb773c000) libicudata.so.42 => /usr/lib/libicudata.so.42 (0xb60f1000) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.