Re: static vs. shared linking

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]

On Mar 24 18:39, David Stacey wrote:
> On 24/03/2015 00:02, David Stacey wrote:
> >I've been having difficulty building poco-1.6.0 for Cygwin for some
> >time. I've managed to produce a test case that shows the problem:
> >
> >https://dl.dropboxusercontent.com/u/119453582/Cygwin/crashtest.tar.xz
> >
> >This archive contains source files that produce a very simple library.
> >When linked statically, the code works fine. However, when linked as a
> >shared DLL, the test crashes with a core dump. The behaviour is
> >identical on x86 and x86_64 architectures.
> >
> >Have I made a stupid error in the compilation of the shared case, or is
> >something more interesting going on?
> 
> I don't know if anyone has managed to look at this. I haven't had a deluge
> of e-mails telling me that I've done something silly (which is a shame,
> because then I could fix it quickly and move on). For the sake of a straw to
> clutch at, I tried compiling with clang++ rather than g++, and got the same
> result:
> 
>     $ ./go.sh
>     Running test (static link)...
>     Done.
> 
>     Running test (shared link)...
>     ./go.sh: line 19:  3744 Aborted                 (core dumped)
> ./shared_test
>     Done.
> 
> Any help or hints would be greatly appreciated.

For a start, you should contemplate to build your test with -g to allow
debugging.  Then you can run the testcase under GDB and get (more or less)
useful output.  The crash occurs in a delete call, afaics.  If you
install the cygwin-debuginfo package, addr2line returns something like this
as the call stack (non-required path components removed):

[...]/cygwin/exceptions.cc:1247
[...]/cygwin/exceptions.cc:1501
[...]/cygwin/sigproc.cc:717
[...]/cygwin/signal.cc:252
[...]/cygwin/signal.cc:303
[...]/cygwin/signal.cc:313
[...]/cygwin/signal.cc:289
[...]/cygwin/signal.cc:375

Everything up to here you can ignore, they are the result of the
abort() call in free(), which occurs here:

[...]/cygwin/malloc.cc:4779
[...]/cygwin/malloc_wrapper.cc:47
[...]/cygwin/sigfe.s:43
[...]/cygwin/libstdcxx_wrapper.cc:69

That's the actual call to the delete method.

/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/ext/new_allocator.h:110
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/bits/basic_string.tcc:449
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/bits/basic_string.h:249
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/bits/basic_string.tcc:512

And this is where it comes from.  It's a call to

  void basic_string<_CharT, _Traits, _Alloc>::reserve(size_type __res)

But, really, I have no idea how this stuff is correlated.  I'm not
a user of libstdc++.  What's noticable is the fact that the crash does
*not* occur because the shared lib is unloaded or something like that.
However, building with -g allows you to step through the code and see
what happens, maybe that gives a clue.


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]