X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Message-ID: <4C1ABA53.501@cwilson.fastmail.fm>
Date: Thu, 17 Jun 2010 20:14:11 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: C++ app segfaults in libstdc++
References: <4C198B44 DOT 6040803 AT cwilson DOT fastmail DOT fm> <4C1A11EF DOT 9000405 AT gmail DOT com> <4C1A2829 DOT 3090602 AT gmail DOT com> <4C1A2BBA DOT 6080805 AT cwilson DOT fastmail DOT fm> <1276788219 DOT 11505 DOT 1380590885 AT webmail DOT messagingengine DOT com> <4C1A7E5D DOT 4070801 AT gmail DOT com>
In-Reply-To: <4C1A7E5D.4070801@gmail.com>
Content-Type: multipart/mixed; boundary="------------060700080600000809000103"
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

--------------060700080600000809000103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

--------------060700080600000809000103
Content-Type: application/octet-stream;
 name="libtool-segfault-stc3.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="libtool-segfault-stc3.tar.bz2"

QlpoOTFBWSZTWbBIryYABmj/ptywAgBc//+ff/fe9P/v3+8ACAABAEAACGAG
P3i+grETYbY0AABxkwTQyGRkZNDQBoMjCAaDRpkMQ0AOMmCaGQyMjJoaANBk
YQDQaNMhiGgBxkwTQyGRkZNDQBoMjCAaDRpkMQ0AEhKmIU08obU2ppoAYI9E
ZND1DQaGg0aAAAilRM1HqDQAAAaGgxBoGgAGQAaAEUhACNABT0GoCRifqgMg
Mm1NGmyjZT1Gm1Nqfavr/tH1xLjhyHt+D9y0JRCQXoqde/u74uu3TF6iplzt
JHbZV7JgsE20K+A2CYIYoJjwgc0f6bGcB8D46K18hpXzYW/m4tPanVudzcs2
/YzD+bXbswKgwhISjFKI6dR0PRbodhYKjFd3pP51hYGRPMnXKyGfT/EnywWw
QQOBkSMEyXovQV9FhRJwo3yShuDVwBlQ8GPEyhnpbEnrD/h7jQwVFlC+q+Cv
sae7qWNO+8rMf+yvxnjLv8l/ca7TrXa5+f95uGhecxzQjRQjURiM07U1rbBB
EQR+2Rwdxy/CuquDz2G09QdxM7eZoNrolrJll9vDdlFTFNOslklDyGnsLZN9
Vef6SWNLJkBHA7q4ncVaiDEyNaTXuIJGBAfZMPKEBgP1Ekg0aTO6pCuQRA/p
RFggYgaYzUSckKudFdWJAgU06SJkB53aewfAOzCSeYtWcFhGogoRLgGCz59O
WkY9wxpUM1PPhtymwXrTVykXIEDMQwOAvpQpLMIMpz7Nl4jXek3I7zjY5RKa
abajqVTjPFeMJBMW1usS488BL08J5Hue/WQi0Ssuks0hYJ/yWCi2hg130Wiz
AsX6i1baZVyZR9MLeM76XwVFt3pnZfX5VmTuwCL1rpKOc8ALliQ2V3yuqLsa
6srQqAgKErrbaTlOCyLrRqVUdtKJOsnJMhqLUnYx6dRRp2At0F1uyb5wmMY3
SjWNjjkwmdI2xNGgkjM9YcZt/Y7RnN7KSji8w0lKNkTvEm+Yk9pYwbQ1oGnz
iWBuAkEyEkGI+kTIfoBKAb2cMMXXKcRJDXAnEM6rT5T1qV5uew9oP+ajAD7h
P4yN0wwx9gm7YJ8YkxPs4jsEwJGhTQTAmBQTiUE4ie09i6TIW0T6xfdXvEwx
OfxfImgNCmB2kQ222xkwhgEXBgC4O2eVGqu6eYxJZVvAi0ep1lyLRo0A1wt1
2SYA1iAvQSgfRfhMLtbRUYhJHufeJIhxWRrN54FSH7hrKGsiMzijlQLh4LtM
QIRLgYMhDUfaZo14BX94FSMw8Ncgyfn0IVBOqIrUMDPYeI3DOXzEprBoAXqo
wDLBoUOYS68Sg4iDBDTOO5H7YFy6ihAc0LQgbWpagTuG5S1/9lKIHUdDcbaq
bnE6BxHnBoOSRa7lsohUGTVW2cA/hB4xtXoZJvIQ9WpmcBT2hyQ1mtTiEB2g
V7Du2sjoHfrasV3F5S2B721G0DEajlEEQaUPEdSouvYIPealkmw1HTiSIIIV
mTZtCOh0PT+P0e/8Phf+UMDBc4AyPGeIsWhmtSP37Y2XHL6YOZC2ndJ+KDyJ
B6OpItgnsupQoTkVZh+QyXLSGyqSEqEiemZvGRMNcFlRIA6haFAmLRiAgD0b
xmSGMBA7wJLj5lsQwDB8i8yt6hIrMSiFB53kAmzj6JRLSHxmgeBtQsJG1b2M
yHIZDIU6Vn4nqnMgqEzP94ByU34PghQAyDeXFS0OJAh8rIeRYcl/osEzv1PX
fOb1CJwX1rwMRmGtb13G/gXJ4jqSJGo8A+Q0GgMh2kcYkbwzK1qrBKhYIBgo
HYGK5x0Q4LYByCBoWhgblJ7hDYWFwaEbTzKELB0alPgu40B2GLwWiHlPGdV1
KvjNhtMkS8dx07UmsMyCcxJE5EKH/xdyRThQkLBIryY=


--------------060700080600000809000103
Content-Type: text/plain; charset=us-ascii

--
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
--------------060700080600000809000103--