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