| Summary: | gdb compiled with mingw32 crashes on Windows7 when entering any invalid command | ||
|---|---|---|---|
| Product: | gdb | Reporter: | David Engster <david> |
| Component: | gdb | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | asmwarrior, brobecker, jon.turney, jon, orgads |
| Priority: | P2 | ||
| Version: | 7.12.1 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Attachments: | config.log file from configure run | ||
Looks like a C++ exception is thrown by error(), but it is not catched in catch_errors(). Trace: 1 msvcrt!abort 2 uw_init_context_1 3 _Unwind_RaiseException 4 __cxa_throw 5 throw_exception_cxx common-exceptions.c 303 6 throw_exception common-exceptions.c 317 7 throw_it common-exceptions.c 373 8 throw_verror common-exceptions.c 379 9 verror utils.c 525 10 error errors.c 43 11 undef_cmd_error cli-decode.c 1475 12 lookup_cmd cli-decode.c 1517 13 execute_command top.c 630 14 command_handler event-top.c 641 15 command_line_handler event-top.c 833 16 gdb_rl_callback_handler event-top.c 213 17 rl_callback_read_char callback.c 220 18 gdb_rl_callback_read_char_wrapper_noexcept event-top.c 175 19 gdb_rl_callback_read_char_wrapper event-top.c 192 20 stdin_event_handler event-top.c 568 21 handle_file_event event-loop.c 733 22 gdb_wait_for_event event-loop.c 884 23 gdb_do_one_event event-loop.c 347 24 gdb_do_one_event common-exceptions.h 225 25 start_event_loop event-loop.c 371 26 captured_command_loop main.c 324 27 catch_errors exceptions.c 236 28 captured_main main.c 1149 29 gdb_main main.c 1159 30 main gdb.c 32 Actually the exception should be catched in gdb_rl_callback_handler. Linking without -static-libstdc++ and -static-libgcc fixes this. There's a pending patch in bug 21187. I just built using the current master, using GCC 6.3.1, and it worked fine for me: (top-gdb) help foobar Undefined command: "foobar". Try "help". I just tested again with gdb 8.0 and gcc 6.3.0 from MSYS2 32bit (i686-w64-mingw32-gcc), and I still see the same problem. I have no idea why it works for you. I can however also confirm that the patch from Orgad in bug 21187 and using "--disable-staticlib" fixes this issue, so it is definitely an issue with static linking. This problem is also seen on x86 Cygwin, and same workaround applies. It would be nice if we understood what was going wrong in the unwinder to cause this problem, though... I don't see this issue, I build GDB git master under msys + mingw-w64 mingw-build 5.4 gcc 32 bit version, if you would like to test, I have the binary here: http://forums.codeblocks.org/index.php/topic,22185.0.html, you need to install the official python 2.7 distribution, because my gdb was build against this python. (In reply to asmwarrior from comment #7) > I don't see this issue, I build GDB git master under msys + mingw-w64 > mingw-build 5.4 gcc 32 bit version, if you would like to test, I have the > binary here: http://forums.codeblocks.org/index.php/topic,22185.0.html, you > need to install the official python 2.7 distribution, because my gdb was > build against this python. Since it seems to be something to do with unwinding across DLL boundaries, I'm going to wildly guess that building without --with-system-readline also prevents this problem. I've also just come across this on 32-bit Cygwin. Strangely, gdb 8.0 is fine, when compiled with gcc 6.4.0 and 7.3.0. However, gdb 8.1 and 8.1.1 both have the problem, when compiled with gcc 6.4.0 or 7.3.0. Removing -static-libstdc++ -static-libgcc LDFLAGS fixes it as above. |
Created attachment 9770 [details] config.log file from configure run I have built the latest gdb (7.12.1) with i686-w64-mingw32 (gcc v6.3.0, MSYS2) on a Windows 7 64bit system, simply using ./configure --prefix=/opt/gdb (I attached the config.log to this report.) When I start gdb and enter any invalid command that would normally lead to an error message (like "help foobar"), the process just aborts (like from an unhandled exception): (gdb) help foobar This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Version 7.12 has the same problem, but 7.11 works fine, so this must be triggered by something since 7.11. I also tried building with the old mingw gcc from mingw.org, but it has the same problem. Unfortunately, I cannot seem to be able to obtain any backtrace when running this inside another gdb. I also tried other gdb v7.12 binary builds, and some have the same problem, for instance the gdb in the latest Linaro toolchain for Arm, or the 'gdb' that can be installed in MSYS2. However, the build from Eli Zaretskii (ezwinports) works fine.