Crashes inside libgcc_s_dw2-1.dll

Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii]

[Please CC me on replies, as I'm not a subscriber.]

Would someone on the developers' team please comment on this problem:

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00413.html

In a nutshell, loading a GnuTLS DLL by a MinGW compiled Emacs causes
libintl DLL to be loaded, and if that libintl DLL in turns loads
libgcc_s_dw2-1.dll, the program crashes inside libgcc on exit, when
the runtime unloads all the DLLs loaded by Emacs.  A related
discussion on the MinGW mailing list

  https://sourceforge.net/mailarchive/message.php?msg_id=30633081

Suggests that this is a general problem with DLLs linked against a
shared libgcc that uses dw2 unwinding.

Is there a bug in libgcc's dw2 unwinding code?  Is it a fundamental
mistake to build DLLs that depend on libgcc as a shared library?  Or
are the applications using libgcc_s_dw2-1.dll buggy and need to get
their act together in some way (if so, how)?  Or anything else?

Thanks in advance.

Re: Crashes inside libgcc_s_dw2-1.dll

[Ian Lance Taylor]

On Sun, May 19, 2013 at 10:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Would someone on the developers' team please comment on this problem:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00413.html
>
> In a nutshell, loading a GnuTLS DLL by a MinGW compiled Emacs causes
> libintl DLL to be loaded, and if that libintl DLL in turns loads
> libgcc_s_dw2-1.dll, the program crashes inside libgcc on exit, when
> the runtime unloads all the DLLs loaded by Emacs.  A related
> discussion on the MinGW mailing list
>
>   https://sourceforge.net/mailarchive/message.php?msg_id=30633081
>
> Suggests that this is a general problem with DLLs linked against a
> shared libgcc that uses dw2 unwinding.
>
> Is there a bug in libgcc's dw2 unwinding code?  Is it a fundamental
> mistake to build DLLs that depend on libgcc as a shared library?  Or
> are the applications using libgcc_s_dw2-1.dll buggy and need to get
> their act together in some way (if so, how)?  Or anything else?

It is not a fundamental bug to depend on libgcc as a shared library.
The libgcc code is trying to do the right thing when the library is
unloaded.  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.

Ian

Re: Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii]

> Date: Sun, 19 May 2013 17:48:06 -0700
> From: Ian Lance Taylor <iant@google.com>
> Cc: gcc@gcc.gnu.org
> 
> It is not a fundamental bug to depend on libgcc as a shared library.
> The libgcc code is trying to do the right thing when the library is
> unloaded.  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?

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?

Thanks.

Re: Crashes inside libgcc_s_dw2-1.dll

[Kai Tietz]

2013/5/20 Eli Zaretskii <eliz@gnu.org>:
>> Date: Sun, 19 May 2013 17:48:06 -0700
>> From: Ian Lance Taylor <iant@google.com>
>> Cc: gcc@gcc.gnu.org
>>
>> It is not a fundamental bug to depend on libgcc as a shared library.
>> The libgcc code is trying to do the right thing when the library is
>> unloaded.  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.

The issue is there that after an unload of libgcc on pe-coff, the
function __decregister_frame_info_bases might be not called.  See here
in libgcc/config/i386/cyming-crtbegin.c file.  This code is always
static-linked so it tries to invoke later - after DLL's unload -
__gcc_deregister_frame function.  Now GetModuleHandle for DLL-version
of libgcc will fail, due it is already unloaded and it defaults back
to __deregister_frame_info function.

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

Well, AFAICS is this gcc_assert at least for pe-coff pretty useless.
The result of this function is at least in context of
__deregister_frame function ignored.

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

Well, internally of unwind-dw2-fde.c it seems to me that we don't need
the assert for the result of NULL-pointer of
__deregister_frame_info_bases, too.

> Thanks.

Kai

Re: Crashes inside libgcc_s_dw2-1.dll

[Ian Lance Taylor]

On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 19 May 2013 17:48:06 -0700
>> From: Ian Lance Taylor <iant@google.com>
>>
>> It is not a fundamental bug to depend on libgcc as a shared library.
>> The libgcc code is trying to do the right thing when the library is
>> unloaded.  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.

Yes, a disassembly around the address might possibly help, although
not if you are correct about where the problem is happening.

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

Ian

Re: Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii]

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

Anyway, here's the disassembly and the stepping session:

(gdb) info symbol 0x700f6f64
libgcc_s_dw2-1!__deregister_frame_info in section .text of D:\usr\bin\libgcc_s_dw2-1.dll
(gdb) break *0x700f6f64
Breakpoint 4 at 0x700f6f64
(gdb) c
Continuing.
[New Thread 48596.0xb844]
[New Thread 48596.0xbc74]
[New Thread 48596.0xbc44]
[Thread 48596.0xbe68 exited with code 0]

Breakpoint 4, 0x700f6f64 in libgcc_s_dw2-1!__deregister_frame_info ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
(gdb) display/i $pc
1: x/i $pc
=> 0x700f6f64 <libgcc_s_dw2-1!__deregister_frame_info>:
    jmp    0x700f6da8 <libgcc_s_dw2-1!__deregister_frame_info_bases>
(gdb) ni
0x700f6da8 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6da8 <libgcc_s_dw2-1!__deregister_frame_info_bases>:   push   %esi
(gdb)
0x700f6da9 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6da9 <libgcc_s_dw2-1!__deregister_frame_info_bases+1>: push   %ebx
(gdb) ni
0x700f6daa in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6daa <libgcc_s_dw2-1!__deregister_frame_info_bases+2>:
    sub    $0x14,%esp
(gdb)
0x700f6dad in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dad <libgcc_s_dw2-1!__deregister_frame_info_bases+5>:
    mov    0x20(%esp),%esi
(gdb)
0x700f6db1 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6db1 <libgcc_s_dw2-1!__deregister_frame_info_bases+9>:
    test   %esi,%esi
(gdb) disassemble
Dump of assembler code for function libgcc_s_dw2-1!__deregister_frame_info_bases:
   0x700f6da8 <+0>:     push   %esi
   0x700f6da9 <+1>:     push   %ebx
   0x700f6daa <+2>:     sub    $0x14,%esp
   0x700f6dad <+5>:     mov    0x20(%esp),%esi
=> 0x700f6db1 <+9>:     test   %esi,%esi
   0x700f6db3 <+11>:    je     0x700f6ee8 <libgcc_s_dw2-1!__deregister_frame_info_bases+320>
   0x700f6db9 <+17>:    mov    (%esi),%eax
   0x700f6dbb <+19>:    test   %eax,%eax
   0x700f6dbd <+21>:    je     0x700f6ee8 <libgcc_s_dw2-1!__deregister_frame_info_bases+320>
   0x700f6dc3 <+27>:    mov    0x700f901c,%eax
   0x700f6dc8 <+32>:    test   %eax,%eax
   0x700f6dca <+34>:    je     0x700f6def <libgcc_s_dw2-1!__deregister_frame_info_bases+71>
   0x700f6dcc <+36>:    mov    0x700f900c,%ebx
   0x700f6dd2 <+42>:    test   %ebx,%ebx
   0x700f6dd4 <+44>:    je     0x700f6e68 <libgcc_s_dw2-1!__deregister_frame_info_bases+192>
   0x700f6dda <+50>:    movl   $0x700fe038,(%esp)
   0x700f6de1 <+57>:    call   0x700f8140 <libgcc_s_dw2-1!__emutls_register_common+1872>
   0x700f6de6 <+62>:    push   %ecx
   0x700f6de7 <+63>:    test   %eax,%eax
   0x700f6de9 <+65>:    jne    0x700f6ef4 <libgcc_s_dw2-1!__deregister_frame_info_bases+332>
   0x700f6def <+71>:    mov    0x700fe040,%eax
   0x700f6df4 <+76>:    test   %eax,%eax
   0x700f6df6 <+78>:    je     0x700f6e16 <libgcc_s_dw2-1!__deregister_frame_info_bases+110>
   0x700f6df8 <+80>:    cmp    %esi,0xc(%eax)
   0x700f6dfb <+83>:    jne    0x700f6e0f <libgcc_s_dw2-1!__deregister_frame_info_bases+103>
   0x700f6dfd <+85>:    jmp    0x700f6f51 <libgcc_s_dw2-1!__deregister_frame_info_bases+425>
   0x700f6e02 <+90>:    xchg   %ax,%ax
   0x700f6e04 <+92>:    cmp    %esi,0xc(%ebx)
   0x700f6e07 <+95>:    je     0x700f6ea8 <libgcc_s_dw2-1!__deregister_frame_info_bases+256>
   0x700f6e0d <+101>:   mov    %ebx,%eax
   0x700f6e0f <+103>:   mov    0x14(%eax),%ebx
   0x700f6e12 <+106>:   test   %ebx,%ebx
   0x700f6e14 <+108>:   jne    0x700f6e04 <libgcc_s_dw2-1!__deregister_frame_info_bases+92>
   0x700f6e16 <+110>:   mov    0x700fe044,%ebx
   0x700f6e1c <+116>:   test   %ebx,%ebx
   0x700f6e1e <+118>:   je     0x700f6e4d <libgcc_s_dw2-1!__deregister_frame_info_bases+165>
   0x700f6e20 <+120>:   mov    $0x700fe044,%eax
   0x700f6e25 <+125>:   jmp    0x700f6e3d <libgcc_s_dw2-1!__deregister_frame_info_bases+149>
   0x700f6e27 <+127>:   nop
   0x700f6e28 <+128>:   mov    0xc(%ebx),%edx
   0x700f6e2b <+131>:   cmp    %esi,(%edx)
   0x700f6e2d <+133>:   je     0x700f6f28 <libgcc_s_dw2-1!__deregister_frame_info_bases+384>
   0x700f6e33 <+139>:   lea    0x14(%ebx),%eax
   0x700f6e36 <+142>:   mov    0x14(%ebx),%ebx
   0x700f6e39 <+145>:   test   %ebx,%ebx
   0x700f6e3b <+147>:   je     0x700f6e4d <libgcc_s_dw2-1!__deregister_frame_info_bases+165>
   0x700f6e3d <+149>:   testb  $0x1,0x10(%ebx)
   0x700f6e41 <+153>:   jne    0x700f6e28 <libgcc_s_dw2-1!__deregister_frame_info_bases+128>
   0x700f6e43 <+155>:   cmp    %esi,0xc(%ebx)
   0x700f6e46 <+158>:   jne    0x700f6e33 <libgcc_s_dw2-1!__deregister_frame_info_bases+139>
   0x700f6e48 <+160>:   mov    0x14(%ebx),%edx
   0x700f6e4b <+163>:   mov    %edx,(%eax)
   0x700f6e4d <+165>:   mov    0x700f901c,%ecx
   0x700f6e53 <+171>:   test   %ecx,%ecx
   0x700f6e55 <+173>:   jne    0x700f6eb0 <libgcc_s_dw2-1!__deregister_frame_info_bases+264>
   0x700f6e57 <+175>:   test   %ebx,%ebx
   0x700f6e59 <+177>:   je     0x700f6f5d <libgcc_s_dw2-1!__deregister_frame_info_bases+437>
   0x700f6e5f <+183>:   mov    %ebx,%eax
   0x700f6e61 <+185>:   add    $0x14,%esp
   0x700f6e64 <+188>:   pop    %ebx
   0x700f6e65 <+189>:   pop    %esi
   0x700f6e66 <+190>:   ret
   0x700f6e67 <+191>:   nop
   0x700f6e68 <+192>:   movl   $0x700f9010,(%esp)
   0x700f6e6f <+199>:   call   0x700f8140 <libgcc_s_dw2-1!__emutls_register_common+1872>
   0x700f6e74 <+204>:   push   %edx
   0x700f6e75 <+205>:   test   %eax,%eax
   0x700f6e77 <+207>:   jne    0x700f6e8d <libgcc_s_dw2-1!__deregister_frame_info_bases+229>
   0x700f6e79 <+209>:   jmp    0x700f6f3d <libgcc_s_dw2-1!__deregister_frame_info_bases+405>
   0x700f6e7e <+214>:   xchg   %ax,%ax
   0x700f6e80 <+216>:   movl   $0x0,(%esp)
   0x700f6e87 <+223>:   call   0x700f8148 <libgcc_s_dw2-1!__emutls_register_common+1880>
   0x700f6e8c <+228>:   push   %eax
   0x700f6e8d <+229>:   mov    0x700f900c,%eax
   0x700f6e92 <+234>:   test   %eax,%eax
   0x700f6e94 <+236>:   je     0x700f6e80 <libgcc_s_dw2-1!__deregister_frame_info_bases+216>
   0x700f6e96 <+238>:   mov    0x700f901c,%eax
   0x700f6e9b <+243>:   test   %eax,%eax
   0x700f6e9d <+245>:   je     0x700f6def <libgcc_s_dw2-1!__deregister_frame_info_bases+71>
   0x700f6ea3 <+251>:   jmp    0x700f6dda <libgcc_s_dw2-1!__deregister_frame_info_bases+50>
   0x700f6ea8 <+256>:   add    $0x14,%eax
   0x700f6eab <+259>:   jmp    0x700f6e48 <libgcc_s_dw2-1!__deregister_frame_info_bases+160>
   0x700f6ead <+261>:   lea    0x0(%esi),%esi
   0x700f6eb0 <+264>:   movl   $0x700fe038,(%esp)
   0x700f6eb7 <+271>:   call   0x700f8198 <libgcc_s_dw2-1!__emutls_register_common+1960>
   0x700f6ebc <+276>:   push   %edx
   0x700f6ebd <+277>:   test   %eax,%eax
   0x700f6ebf <+279>:   js     0x700f6e57 <libgcc_s_dw2-1!__deregister_frame_info_bases+175>
   0x700f6ec1 <+281>:   movl   $0x0,0x8(%esp)
   0x700f6ec9 <+289>:   movl   $0x1,0x4(%esp)
   0x700f6ed1 <+297>:   mov    0x700fe03c,%eax
   0x700f6ed6 <+302>:   mov    %eax,(%esp)
   0x700f6ed9 <+305>:   call   0x700f81a0 <libgcc_s_dw2-1!__emutls_register_common+1968>
   0x700f6ede <+310>:   sub    $0xc,%esp
   0x700f6ee1 <+313>:   jmp    0x700f6e57 <libgcc_s_dw2-1!__deregister_frame_info_bases+175>
   0x700f6ee6 <+318>:   xchg   %ax,%ax
   0x700f6ee8 <+320>:   xor    %ebx,%ebx
   0x700f6eea <+322>:   mov    %ebx,%eax
   0x700f6eec <+324>:   add    $0x14,%esp
   0x700f6eef <+327>:   pop    %ebx
   0x700f6ef0 <+328>:   pop    %esi
   0x700f6ef1 <+329>:   ret
   0x700f6ef2 <+330>:   xchg   %ax,%ax
   0x700f6ef4 <+332>:   movl   $0xffffffff,0x4(%esp)
   0x700f6efc <+340>:   mov    0x700fe03c,%eax
   0x700f6f01 <+345>:   mov    %eax,(%esp)
   0x700f6f04 <+348>:   call   0x700f8190 <libgcc_s_dw2-1!__emutls_register_common+1952>
   0x700f6f09 <+353>:   sub    $0x8,%esp
   0x700f6f0c <+356>:   test   %eax,%eax
   0x700f6f0e <+358>:   je     0x700f6def <libgcc_s_dw2-1!__deregister_frame_info_bases+71>
   0x700f6f14 <+364>:   movl   $0x700fe038,(%esp)
   0x700f6f1b <+371>:   call   0x700f8198 <libgcc_s_dw2-1!__emutls_register_common+1960>
   0x700f6f20 <+376>:   push   %ebx
   0x700f6f21 <+377>:   jmp    0x700f6def <libgcc_s_dw2-1!__deregister_frame_info_bases+71>
   0x700f6f26 <+382>:   xchg   %ax,%ax
   0x700f6f28 <+384>:   mov    0x14(%ebx),%edx
   0x700f6f2b <+387>:   mov    %edx,(%eax)
   0x700f6f2d <+389>:   mov    0xc(%ebx),%eax
   0x700f6f30 <+392>:   mov    %eax,(%esp)
   0x700f6f33 <+395>:   call   0x700f80d0 <libgcc_s_dw2-1!__emutls_register_common+1760>
   0x700f6f38 <+400>:   jmp    0x700f6e4d <libgcc_s_dw2-1!__deregister_frame_info_bases+165>
   0x700f6f3d <+405>:   call   0x700f57c0 <libgcc_s_dw2-1!_Unwind_Backtrace+972>

   0x700f6f42 <+410>:   movl   $0x1,0x700f900c
   0x700f6f4c <+420>:   jmp    0x700f6e96 <libgcc_s_dw2-1!__deregister_frame_info_bases+238>
   0x700f6f51 <+425>:   mov    %eax,%ebx
   0x700f6f53 <+427>:   mov    $0x700fe040,%eax
   0x700f6f58 <+432>:   jmp    0x700f6e48 <libgcc_s_dw2-1!__deregister_frame_info_bases+160>
   0x700f6f5d <+437>:   call   0x700f80f8 <libgcc_s_dw2-1!__emutls_register_common+1800>
   0x700f6f62 <+442>:   xchg   %ax,%ax
End of assembler dump.
(gdb) ni
0x700f6db3 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6db3 <libgcc_s_dw2-1!__deregister_frame_info_bases+11>:
    je     0x700f6ee8 <libgcc_s_dw2-1!__deregister_frame_info_bases+320>
(gdb)
[Thread 48596.0xbc44 exited with code 0]
[Thread 48596.0xb844 exited with code 0]
0x700f6db9 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6db9 <libgcc_s_dw2-1!__deregister_frame_info_bases+17>:
    mov    (%esi),%eax
(gdb)
0x700f6dbb in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dbb <libgcc_s_dw2-1!__deregister_frame_info_bases+19>:
    test   %eax,%eax
(gdb)
0x700f6dbd in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dbd <libgcc_s_dw2-1!__deregister_frame_info_bases+21>:
    je     0x700f6ee8 <libgcc_s_dw2-1!__deregister_frame_info_bases+320>
(gdb)
0x700f6dc3 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dc3 <libgcc_s_dw2-1!__deregister_frame_info_bases+27>:
    mov    0x700f901c,%eax
(gdb)
0x700f6dc8 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dc8 <libgcc_s_dw2-1!__deregister_frame_info_bases+32>:
    test   %eax,%eax
(gdb)
0x700f6dca in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dca <libgcc_s_dw2-1!__deregister_frame_info_bases+34>:
    je     0x700f6def <libgcc_s_dw2-1!__deregister_frame_info_bases+71>
(gdb)
0x700f6dcc in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dcc <libgcc_s_dw2-1!__deregister_frame_info_bases+36>:
    mov    0x700f900c,%ebx
(gdb)
0x700f6dd2 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dd2 <libgcc_s_dw2-1!__deregister_frame_info_bases+42>:
    test   %ebx,%ebx
(gdb)
0x700f6dd4 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dd4 <libgcc_s_dw2-1!__deregister_frame_info_bases+44>:
    je     0x700f6e68 <libgcc_s_dw2-1!__deregister_frame_info_bases+192>
(gdb)
0x700f6dda in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dda <libgcc_s_dw2-1!__deregister_frame_info_bases+50>:
    movl   $0x700fe038,(%esp)
(gdb)
0x700f6de1 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6de1 <libgcc_s_dw2-1!__deregister_frame_info_bases+57>:
    call   0x700f8140 <libgcc_s_dw2-1!__emutls_register_common+1872>
(gdb) ni
0x700f8140 in libgcc_s_dw2-1!__emutls_register_common ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f8140 <libgcc_s_dw2-1!__emutls_register_common+1872>:
    jmp    *0x701000f4
(gdb)
0x75b91400 in KERNEL32!InterlockedIncrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91400 <KERNEL32!InterlockedIncrement>:  mov    %edi,%edi
(gdb)
0x75b91402 in KERNEL32!InterlockedIncrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91402 <KERNEL32!InterlockedIncrement+2>:        push   %ebp
(gdb)
0x75b91403 in KERNEL32!InterlockedIncrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91403 <KERNEL32!InterlockedIncrement+3>:        mov    %esp,%ebp
(gdb)
0x75b91405 in KERNEL32!InterlockedIncrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91405 <KERNEL32!InterlockedIncrement+5>:        pop    %ebp
(gdb)
0x75b91406 in KERNEL32!InterlockedIncrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91406 <KERNEL32!InterlockedIncrement+6>:
    jmp    0x75b91380 <KERNEL32!GetConsoleMode+88>
(gdb)
0x75b91380 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91380 <KERNEL32!GetConsoleMode+88>:     mov    0x4(%esp),%ecx
(gdb)
0x75b91384 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91384 <KERNEL32!GetConsoleMode+92>:     mov    $0x1,%eax
(gdb)
0x75b91389 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91389 <KERNEL32!GetConsoleMode+97>:     lock xadd %eax,(%ecx)
(gdb)
0x75b9138d in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b9138d <KERNEL32!GetConsoleMode+101>:    inc    %eax
(gdb)
0x75b9138e in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b9138e <KERNEL32!GetConsoleMode+102>:    ret    $0x4
(gdb)
0x700f6de6 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6de6 <libgcc_s_dw2-1!__deregister_frame_info_bases+62>:
    push   %ecx
(gdb) ni
0x700f6de7 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6de7 <libgcc_s_dw2-1!__deregister_frame_info_bases+63>:
    test   %eax,%eax
(gdb)
0x700f6de9 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6de9 <libgcc_s_dw2-1!__deregister_frame_info_bases+65>:
    jne    0x700f6ef4 <libgcc_s_dw2-1!__deregister_frame_info_bases+332>
(gdb)
0x700f6def in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6def <libgcc_s_dw2-1!__deregister_frame_info_bases+71>:
    mov    0x700fe040,%eax
(gdb)
0x700f6df4 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6df4 <libgcc_s_dw2-1!__deregister_frame_info_bases+76>:
    test   %eax,%eax
(gdb)
0x700f6df6 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6df6 <libgcc_s_dw2-1!__deregister_frame_info_bases+78>:
    je     0x700f6e16 <libgcc_s_dw2-1!__deregister_frame_info_bases+110>
(gdb)
0x700f6df8 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6df8 <libgcc_s_dw2-1!__deregister_frame_info_bases+80>:
    cmp    %esi,0xc(%eax)
(gdb)
0x700f6dfb in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6dfb <libgcc_s_dw2-1!__deregister_frame_info_bases+83>:
    jne    0x700f6e0f <libgcc_s_dw2-1!__deregister_frame_info_bases+103>
(gdb)
0x700f6e0f in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e0f <libgcc_s_dw2-1!__deregister_frame_info_bases+103>:
    mov    0x14(%eax),%ebx
(gdb)
0x700f6e12 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e12 <libgcc_s_dw2-1!__deregister_frame_info_bases+106>:
    test   %ebx,%ebx
(gdb)
0x700f6e14 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e14 <libgcc_s_dw2-1!__deregister_frame_info_bases+108>:
    jne    0x700f6e04 <libgcc_s_dw2-1!__deregister_frame_info_bases+92>
(gdb)
0x700f6e04 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e04 <libgcc_s_dw2-1!__deregister_frame_info_bases+92>:
    cmp    %esi,0xc(%ebx)
(gdb)
0x700f6e07 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e07 <libgcc_s_dw2-1!__deregister_frame_info_bases+95>:
    je     0x700f6ea8 <libgcc_s_dw2-1!__deregister_frame_info_bases+256>
(gdb)
0x700f6e0d in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e0d <libgcc_s_dw2-1!__deregister_frame_info_bases+101>:
    mov    %ebx,%eax
(gdb)
0x700f6e0f in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e0f <libgcc_s_dw2-1!__deregister_frame_info_bases+103>:
    mov    0x14(%eax),%ebx
(gdb)
0x700f6e12 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e12 <libgcc_s_dw2-1!__deregister_frame_info_bases+106>:
    test   %ebx,%ebx
(gdb)
0x700f6e14 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e14 <libgcc_s_dw2-1!__deregister_frame_info_bases+108>:
    jne    0x700f6e04 <libgcc_s_dw2-1!__deregister_frame_info_bases+92>
(gdb)
0x700f6e16 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e16 <libgcc_s_dw2-1!__deregister_frame_info_bases+110>:
    mov    0x700fe044,%ebx
(gdb)
0x700f6e1c in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e1c <libgcc_s_dw2-1!__deregister_frame_info_bases+116>:
    test   %ebx,%ebx
(gdb)
0x700f6e1e in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e1e <libgcc_s_dw2-1!__deregister_frame_info_bases+118>:
    je     0x700f6e4d <libgcc_s_dw2-1!__deregister_frame_info_bases+165>
(gdb)
0x700f6e4d in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e4d <libgcc_s_dw2-1!__deregister_frame_info_bases+165>:
    mov    0x700f901c,%ecx
(gdb)
0x700f6e53 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e53 <libgcc_s_dw2-1!__deregister_frame_info_bases+171>:
    test   %ecx,%ecx
(gdb)
0x700f6e55 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e55 <libgcc_s_dw2-1!__deregister_frame_info_bases+173>:
    jne    0x700f6eb0 <libgcc_s_dw2-1!__deregister_frame_info_bases+264>
(gdb)
0x700f6eb0 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6eb0 <libgcc_s_dw2-1!__deregister_frame_info_bases+264>:
    movl   $0x700fe038,(%esp)
(gdb)
0x700f6eb7 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6eb7 <libgcc_s_dw2-1!__deregister_frame_info_bases+271>:
    call   0x700f8198 <libgcc_s_dw2-1!__emutls_register_common+1960>
(gdb)
0x700f8198 in libgcc_s_dw2-1!__emutls_register_common ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f8198 <libgcc_s_dw2-1!__emutls_register_common+1960>:
    jmp    *0x701000f0
(gdb)
0x75b913f0 in KERNEL32!InterlockedDecrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913f0 <KERNEL32!InterlockedDecrement>:  mov    %edi,%edi
(gdb)
0x75b913f2 in KERNEL32!InterlockedDecrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913f2 <KERNEL32!InterlockedDecrement+2>:        push   %ebp
(gdb)
0x75b913f3 in KERNEL32!InterlockedDecrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913f3 <KERNEL32!InterlockedDecrement+3>:        mov    %esp,%ebp
(gdb)
0x75b913f5 in KERNEL32!InterlockedDecrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913f5 <KERNEL32!InterlockedDecrement+5>:        pop    %ebp
(gdb)
0x75b913f6 in KERNEL32!InterlockedDecrement ()
   from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913f6 <KERNEL32!InterlockedDecrement+6>:
    jmp    0x75b91394 <KERNEL32!GetConsoleMode+108>
(gdb)
0x75b91394 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91394 <KERNEL32!GetConsoleMode+108>:    mov    0x4(%esp),%ecx
(gdb)
0x75b91398 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b91398 <KERNEL32!GetConsoleMode+112>:    mov    $0xffffffff,%eax
(gdb)
0x75b9139d in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b9139d <KERNEL32!GetConsoleMode+117>:    lock xadd %eax,(%ecx)
(gdb)
0x75b913a1 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913a1 <KERNEL32!GetConsoleMode+121>:    dec    %eax
(gdb)
0x75b913a2 in KERNEL32!GetConsoleMode () from C:\Windows\syswow64\kernel32.dll
1: x/i $pc
=> 0x75b913a2 <KERNEL32!GetConsoleMode+122>:    ret    $0x4
(gdb)
0x700f6ebc in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6ebc <libgcc_s_dw2-1!__deregister_frame_info_bases+276>:
    push   %edx
(gdb) ni
0x700f6ebd in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6ebd <libgcc_s_dw2-1!__deregister_frame_info_bases+277>:
    test   %eax,%eax
(gdb)
0x700f6ebf in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6ebf <libgcc_s_dw2-1!__deregister_frame_info_bases+279>:
    js     0x700f6e57 <libgcc_s_dw2-1!__deregister_frame_info_bases+175>
(gdb)
0x700f6e57 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e57 <libgcc_s_dw2-1!__deregister_frame_info_bases+175>:
    test   %ebx,%ebx
(gdb)
0x700f6e59 in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6e59 <libgcc_s_dw2-1!__deregister_frame_info_bases+177>:
    je     0x700f6f5d <libgcc_s_dw2-1!__deregister_frame_info_bases+437>
(gdb)
0x700f6f5d in libgcc_s_dw2-1!__deregister_frame_info_bases ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f6f5d <libgcc_s_dw2-1!__deregister_frame_info_bases+437>:
    call   0x700f80f8 <libgcc_s_dw2-1!__emutls_register_common+1800>
(gdb)
0x700f80f8 in libgcc_s_dw2-1!__emutls_register_common ()
   from D:\usr\bin\libgcc_s_dw2-1.dll
1: x/i $pc
=> 0x700f80f8 <libgcc_s_dw2-1!__emutls_register_common+1800>:
    jmp    *0x70100134
(gdb)
0x753f8e6b in msvcrt!abort () from C:\Windows\syswow64\msvcrt.dll
1: x/i $pc
=> 0x753f8e6b <msvcrt!abort>:   mov    %edi,%edi
(gdb)

Re: Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii]

> Date: Mon, 20 May 2013 12:18:29 +0200
> From: Kai Tietz <ktietz70@googlemail.com>
> Cc: Ian Lance Taylor <iant@google.com>, gcc Mailing List <gcc@gcc.gnu.org>
> 
> The issue is there that after an unload of libgcc on pe-coff, the
> function __decregister_frame_info_bases might be not called.

That's probably true (assuming that cygming-crtbegin.c decided at
startup time that libgcc DLL is loaded).  But this cannot be the whole
story, because the call to 'abort' happens before libgcc is unloaded
at program exit time.  See my other message I just sent in this
thread.  If I set a breakpoint on __decregister_frame_info_bases, I
see that it calls 'abort' the very first time it is called, when
libgcc is still very much loaded into the process.

Thanks.

Re: Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii]

> 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

Re: Crashes inside libgcc_s_dw2-1.dll

[Ian Lance Taylor]

On Tue, Jun 4, 2013 at 9:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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?

I know very little about how these things work on Windows.  However,
it is fairly likely that full support for throwing exceptions across
shared libraries on Windows does require using a shared libgcc.  And
as far as I know that should be the default.  That is how things used
to work on GNU/Linux, before the linker's --eh-frame-hdr option was
introduced.

Ian

Re: Crashes inside libgcc_s_dw2-1.dll

[Eli Zaretskii]

> Date: Tue, 4 Jun 2013 09:45:10 -0700
> From: Ian Lance Taylor <iant@google.com>
> Cc: gcc@gcc.gnu.org
> 
> I know very little about how these things work on Windows.  However,
> it is fairly likely that full support for throwing exceptions across
> shared libraries on Windows does require using a shared libgcc.

Indeed, throwing exceptions across DLLs requires a shared libgcc.  But
that wasn't the issue.  The issue was why does the shared libgcc abort
at program exit, if it is loaded dynamically as a side effect of
loading another shared library (in this case, libintl) some time
during the run of the main program?

To recap: Emacs loads GnuTLS when the user starts a TLS session, and
that in turn loads libintl and the shared libgcc.  Then, when Emacs
exits, there's an abort inside libgcc, where there's some assertion.
The details are in the message I posted on May 21.

My question was: is this expected?  Does a program that loads the
shared libgcc in mid-flight need to be linked with -shared-libgcc
flag?  Or is this some bug in libgcc?

Thanks.

Re: Crashes inside libgcc_s_dw2-1.dll

[Ian Lance Taylor]

On Tue, Jun 4, 2013 at 10:13 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> My question was: is this expected?  Does a program that loads the
> shared libgcc in mid-flight need to be linked with -shared-libgcc
> flag?  Or is this some bug in libgcc?

I don't think anybody knows the answer to that.

I doubt the behaviour was planned.

Ian

Re: Crashes inside libgcc_s_dw2-1.dll

[Nicholas Clifton]

Hi Eli,

   Corinna has asked me to take a look at your bug report[1] on this 
problem (since she has now encountered it in an Cygwin environment). 
Unfortunately I am not an x86 expert so I am not really able to dig 
deeply into it.  But what I would recommend is filing an official gcc 
bug report and then pinging the x86 gcc maintainers to see if you can 
persuade them that it is a problem worth investigating.

   If that fails, please could you ping me directly and I will try to 
have a go at fixing the problem myself.  No promises on solving it 
though... :-)

Cheers
   Nick

[1]: https://gcc.gnu.org/ml/gcc/2013-05/msg00214.html