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: Kai Tietz <ktietz70 at googlemail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Ian Lance Taylor <iant at google dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 20 May 2013 12:18:29 +0200
- Subject: Re: Crashes inside libgcc_s_dw2-1.dll
- References: <83obc6x4fh dot fsf at gnu dot org> <CAKOQZ8zJNiJ+d+GM-kiaXKDEKnTEGJKX1T860pvGVBgHEEeYWQ at mail dot gmail dot com> <83d2smwc2m dot fsf at gnu dot org>
2013/5/20 Eli Zaretskii <eliz@gnu.org>:
>> Date: Sun, 19 May 2013 17:48:06 -0700
>> From: Ian Lance Taylor <iant@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