2013/5/20 Eli Zaretskii <e...@gnu.org>: >> Date: Sun, 19 May 2013 17:48:06 -0700 >> From: Ian Lance Taylor <i...@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