Re: C++ app segfaults in libstdc++

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 6/17/2010 3:58 PM, Dave Korn wrote:
> On 17/06/2010 16:23, Charles Wilson wrote:
> 
>> As expected, this didn't work. But...the imports and exports are NOT
>> what I expected, so I'm a little confused:
> 
>> Err, what? (a) why is this DLL exporting modexc stuff, when it is marked
>> dllimport in this context? (b) why is this DLL exporting std::exception
>> stuff?
> 
>   Looks like an e-a-s bug causing linked-in __imp_ symbols to get re-exported.
>  That's not supposed to happen, but if you remove e-a-s (and add the standard
> dllimport/dllexport macro dance in the module .h and .cpp files) you get more
> sensible looking exports.

Ok, see attached.

This looks a *little* more sensible -- in that module.dll doesn't export
stuff it shouldn't -- but shared-data-types.dll still seems to be
missing some of the functions:

shared-data-types.dll exports:
[Ordinal/Name Pointer] Table
        [   0] modexc::~modexc()
        [   1] modexc::~modexc()
        [   2] modexc::what() const
        [   3] vtable for modexc
        [   4] shared_data_types_dummy

e.g. the constructor(std::string) isn't exported (neither are any of the
compiler-generated methods, like the copy constructor or whatnot; but I
don't recall when those are or are-not generated...)  Also, no typeinfo
or typename data seems to be exported.

OTOH, the weeds of what gets "exported" and what doesn't, when dealing
with methods which are all defined inline (even if they don't use the
keyword)...I'm not clear on that.


module.dll exports:
[Ordinal/Name Pointer] Table
        [   0] modbar()
        [   1] modfoo

module.dll imports from shared-data-types.dll:
        DLL Name: shared-data-types.dll
        vma:  Hint/Ord Member-Name Bound-To
        8228        3  vtable for modexc

main.exe imports from shared-data-types.dll:
        DLL Name: shared-data-types.dll
        vma:  Hint/Ord Member-Name Bound-To
        7228        3  vtable for modexc

Of course, it still coredumps, without the following patch, which moves
the dlclose outside of the context where the exception object is "live":

--- main.cpp.old	2010-06-17 19:57:40.496600000 -0400
+++ main.cpp	2010-06-17 20:01:03.372600000 -0400
@@ -19,6 +19,7 @@

 int exceptions_in_module (void)
 {
+  bool was_caught = false;
   std::cerr << "exceptions_in_module\n";

   void *handle = dlopen ("module.dll", RTLD_GLOBAL | RTLD_LAZY);
@@ -41,13 +42,17 @@
   }
   catch (modexc e) {
     std::cerr << "caught: " << e.what () << '\n';
-    if (dlclose (handle))
-      {
-        std::cerr << "dlclose failed: " << dlerror () << '\n';
-        return 1;
-      }
-    return 0;
+    was_caught = true;
   }
+  if (was_caught)
+    {
+      if (dlclose (handle))
+        {
+          std::cerr << "dlclose failed: " << dlerror () << '\n';
+          return 1;
+        }
+      return 0;
+    }
   return 1;
 }

With this patch, it works.



So, I gather there are actually three problems here:

1) ODR issues with the definition of the exception class.  While on
linux, the code may technically be in violation, in practice it is ok
and works. But on win32 with DLLs...it is NOT ok.

2) Violations of the "rule": Don't unload a shared library while you
still have a live C++ object from it, unless that object is a POD.

3) A bug in the linker where --export-all-symbols re-exports symbols
imported from another library.

Right?


#1 and #2 can be fixed in the libtool test code. #3..I don't know if
that's going to be a problem or not.

--
Chuck

Attachment: libtool-segfault-stc3.tar.bz2
Description: Binary data

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple