On Tue, Jun 4, 2013 at 9:39 AM, Eli Zaretskii <e...@gnu.org> wrote: >> Date: Tue, 21 May 2013 21:19:24 +0300 >> From: Eli Zaretskii <e...@gnu.org> >> CC: gcc@gcc.gnu.org >> >> > Date: Mon, 20 May 2013 06:37:31 -0700 >> > From: Ian Lance Taylor <i...@google.com> >> > Cc: gcc@gcc.gnu.org >> > >> > On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii <e...@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
