This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Crashes inside libgcc_s_dw2-1.dll
- From: Ian Lance Taylor <iant at google dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 19 May 2013 17:48:06 -0700
- Subject: Re: Crashes inside libgcc_s_dw2-1.dll
- References: <83obc6x4fh dot fsf at gnu dot org>
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