Re: Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Tue, 21 May 2013 21:19:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gcc@gcc.gnu.org
> 
> > Date: Mon, 20 May 2013 06:37:31 -0700
> > From: Ian Lance Taylor <iant@google.com>
> > Cc: gcc@gcc.gnu.org
> > 
> > On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > >> I don't see any obvious bug in the code.  Evidently
> > >> something is going wrong, but the e-mail messages you linked to don't
> > >> provide enough information to know what it is.  In particular they
> > >> don't show where in __deregister_frame_info_bases the crash is
> > >> occurring.
> > >
> > > I believe that's because the versions of the library which I could
> > > find don't have enough debug information.  Does someone know where can
> > > I find a library with debug info?  Failing that, would a disassembly
> > > near the address where it crashes be useful?
> > 
> > Normally the library should have debug info.  I don't know why it
> > doesn't in your case.
> 
> I don't know either.  Perhaps the person who prepared the MinGW GCC
> package stripped the binaries and the DLLs.  GDB clearly says (in
> "info shared") that the DLL has no debug info.
> 
> > Yes, a disassembly around the address might possibly help, although
> > not if you are correct about where the problem is happening.
> 
> I show the disassembly below.  And since the address from which
> 'abort' was called didn't make much sense (it pointed to the
> instruction _after_ the one that jumped to 'abort'), I also show a
> session of stepping through __deregister_frame_info_bases, with
> display of the instructions that are being stepped through.  I hope
> this gives sufficient info to see what is going on.
> 
> My interpretation of what I saw is that the call to 'abort' is indeed
> from gcc_assert, because it happens immediately after the return from
> __gthread_mutex_unlock, as seen by stepping through the call to
> InterlockedDecrement.
> 
> > > Anyway, what we see is not a crash, but a call to 'abort' from Windows
> > > runtime.  The immediate suspect for that is the line near the end of
> > > __deregister_frame_info_bases where there's a call to gcc_assert.
> > > Does that make sense?
> > 
> > I don't see why that assert would trigger, no.
> 
> I have a theory about this, based on the following observation: if I
> link Emacs with -shared-libgcc, the crashes disappear.
> 
> Looking closer and cygming-crtbegin.c and cygming-crtend.c, I see that
> they both test for the shared libgcc being loaded into the process,
> but they do that independently.  So, if the shared libgcc is loaded
> some time after the program start, as a side effect of loading another
> DLL (it was libintl in the case in point, which was loaded because
> Emacs loaded the GnuTLS library to start a TLS session), crtbegin will
> decide that libgcc DLL is not present, while crtend will decide that
> it is.  Doesn't this asymmetry cause the program to use incompatible
> register and deregister code?  And wouldn't that in turn cause the
> assert to trigger?
> 
> If my theory makes sense, does this mean that loading _any_ DLL that
> depends on libgcc as a shared library _requires_ the program to be
> linked with -shared-libgcc?  If this is indeed so, and by design
> rather than by accident, then it would be an unfortunate restriction,
> since a program can be built on one machine and then the binary
> installed and used on another, with different builds of the same
> DLLs.  Like in this case.

Ping!  Any further comments?  Is my analysis correct?  Does the
program need to be linked with -shared-libgcc?

TIA