[Bug c++/40918] New: uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
I was not able to reproduce the bug on Linux, so I assume this is a
Windows-specific.
If an exception is generated inside shared library (DLL), then crosses the
DLL-boundary and gets caught in some other module, the std::uncaught_exception
will always return wrong (inverted) value from now on. Here's a small test
case.
The DLL (throw.dll) contains just a single function that throws an exception:
throw.cpp
~
void do_throw(void)
{
throw("");
}
The test program (test.exe) is linked against throw.dll:
test.cpp
#include
#include
bool b;
void do_throw(void);
struct UE
{
~UE()
{
b = std::uncaught_exception();
}
};
int main(void)
{
try
{
do_throw();
}
catch (...)
{
}
try
{
UE ue;
throw "";
}
catch (...)
{
}
std::cout << "Expecting 'true', got " << (b ? "'true'" : "'false'") <<
std::endl;
{
UE ue;
}
std::cout << "Expecting 'false', got " << (b ? "'true'" : "'false'") <<
std::endl;
return 0;
}
test.exe produces the following output:
C:\TEMP\bug>test.exe
Expecting 'true', got 'false'
Expecting 'false', got 'true'
If we comment out the call to do_throw(), std::uncaught_exception will work as
expected. If we put do_throw() in a statically linked module,
std::uncaught_exception will work as expected as well.
--
Summary: uncaught_exception() returns wrong (inverted) value if
some exception have crossed a DLL boundary before
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andriys at gmail dot com
GCC host triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #1 from andriys at gmail dot com 2009-07-30 20:22 --- Created an attachment (id=18275) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18275&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #3 from andriys at gmail dot com 2009-07-31 06:56 --- I'm linking using g++ driver, so shared libgcc is enabled by default in 4.4.0. I've just tried to enabled shared libstdc++ as described in the Release Notes to the MinGW GCC 4.4.0 release, which made no difference. More over, I modified the test case the following way: I got rid of std::cout in favor of printf(), added -nodefaultlibs option to the linker and specified all the required libraries manually. Now libstdc++ is not linked at all (neither static nor dynamic), the bug is still here. I'll attach the modified test case shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #4 from andriys at gmail dot com 2009-07-31 06:58 --- Created an attachment (id=18277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18277&action=view) Modified test case (not dependent on libstdc++ at all) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #6 from andriys at gmail dot com 2009-08-04 13:41 --- (In reply to comment #5) > I cannot comment on the build of libsdc++.dll in the mingw 4.4.0 release since > I have not looked at that source. There is a patch file that is shipped along with the mingw 4.4.0 build instructions/script. The patch adds most of the essential things that the Dave Korn's patch does (i.e. __attribute__((dllimport)) decorations and -no-undefined linker option.) I believe the official MinGW binaries were built with that patch applied. Well, there are your E-mail at the top of that patch file... > Applying Dave Korn's patch mentioned in Comment #2, and linking against > libstdc++.dll, I get this with your original testcaase: > > Expecting 'true', got 'true' > Expecting 'false', got 'false' > Where this patch is supposed to be applied to? trunk? I have looked through the patches you are referring to and through the source in repository. As far as I can see, libsupc++ is still static only, and eh_globals.cc is a part of libsupc++, not libstdc++. The fact that test-case works correctly for you could be just a coincidence. The more reliable way to check for the problem would be to compare the value returned by the __cxa_get_globals() when being from the main executable and from the dll respectively. I'll prepare the new test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #7 from andriys at gmail dot com 2009-08-04 13:53 --- Created an attachment (id=18296) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18296&action=view) Yet another test case This test checks whether main executable and dll share common abi::__cxa_eh_globals structure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #3 from andriys at gmail dot com 2010-03-21 08:15 --- (In reply to comment #1) > This is probably due to the way you built GCC. To have a completely > relocatable toolchain, you need to use the --with-sysroot option to configure, I've just checked out the latest sources from trunk, as well as consulted the previously fetched sources. There are no such option to configure as --with-sysroot. Did you mean --with-build-sysroot? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug target/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #9 from andriys at gmail dot com 2010-01-26 12:16 --- Well, I have finally managed to build the trunk on Windows (mingw32). Now all test cases work fine for me without any patches (as of revision 156168 at least). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug regression/42886] New: [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
When invoking gcc from where it was installed by 'make install' (C:\MinGW\bin) everything works as expected. But as soon as I move the C:\MinGW directory into some other location standard header files are not looked up at the default locations any more. For example if MinGW directory is moved to C:\DevTools and gcc is invoked from C:\DevTools\MinGW\bin, standard headers are not looked up in the C:\DevTools\MinGW\include directory. Additionally, localization stops working after the relocation. To illustrate the problem: C:\>set PATH=C:\MinGW\bin;%PATH% C:\>echo "" | cpp -v Используются внутренние спецификации. COLLECT_GCC=cpp COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Целевая архитектура: mingw32 Параметры конфигурации: ../gcc_trunk/configure --enable-languages=c,c++ --disable-sjlj-exceptions --enable-shared --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --build=mingw32 Модель многопоточности: win32 gcc версия 4.5.0 20100122 (experimental) [trunk revision 150484] (GCC) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/4.5.0/ - -mtune=i386 повторное задание каталога "/mingw/include" проигнорировано повторное задание каталога "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include" проигнорировано повторное задание каталога "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed" проигнорировано повторное задание каталога "/mingw/include" проигнорировано порядок поиска для #include "...": порядок поиска для #include <...>: c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include-fixed c:/MinGW/include c:/mingw/lib/gcc/../../mingw32/include конец списка поиска # 1 "" # 1 "" # 1 "" # 1 "" COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.5.0/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../;/mingw/lib/ COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' C:\>move MinGW C:\DevTools\ C:\>set PATH=C:\DevTools\MinGW\bin;%PATH% C:\>echo "" | cpp -v Using built-in specs. COLLECT_GCC=cpp COLLECT_LTO_WRAPPER=c:/devtools/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc_trunk/configure --enable-languages=c,c++ --disable-sjlj-exceptions --enable-shared --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --build=mingw32 Thread model: win32 gcc version 4.5.0 20100122 (experimental) [trunk revision 150484] (GCC) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' c:/devtools/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v -iprefix c:\devtools\mingw\bin\../lib/gcc/mingw32/4.5.0/ - -mtune=i386 ignoring nonexistent directory "c:/MinGW/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "c:/devtools/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include" ignoring duplicate directory "c:/devtools/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\devtools\mingw\bin\../lib/gcc/mingw32/4.5.0/include c:\devtools\mingw\bin\../lib/gcc/mingw32/4.5.0/include-fixed c:/devtools/mingw/lib/gcc/../../mingw32/include End of search list. # 1 "" # 1 "" # 1 "" # 1 "" COMPILER_PATH=c:/devtools/mingw/bin/../libexec/gcc/mingw32/4.5.0/;c:/devtools/mingw/bin/../libexec/gcc/;c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ LIBRARY_PATH=c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/;c:/devtools/mingw/bin/../lib/gcc/;c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib/;c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../ COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' -- Summary: [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andriys at gmail dot com GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
