Crashes inside libgcc_s_dw2-1.dll
[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.
gcc-4.9-20130519 is now available
Snapshot gcc-4.9-20130519 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130519/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 199087 You'll find: gcc-4.9-20130519.tar.bz2 Complete GCC MD5=b05ffe5b390fdfab7ab5066c20f00b57 SHA1=dcebb2530fbe628f9ddc4a7bf945724c7b1f74ac Diffs from 4.9-20130512 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Crashes inside libgcc_s_dw2-1.dll
On Sun, May 19, 2013 at 10:30 AM, Eli Zaretskii 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
> Date: Sun, 19 May 2013 17:48:06 -0700 > From: Ian Lance Taylor > 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.
