Bug 21078 - gdb compiled with mingw32 crashes on Windows7 when entering any invalid command
Summary: gdb compiled with mingw32 crashes on Windows7 when entering any invalid command
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.12.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-24 16:11 UTC by David Engster
Modified: 2018-08-20 13:31 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
config.log file from configure run (6.28 KB, text/plain)
2017-01-24 16:11 UTC, David Engster
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Engster 2017-01-24 16:11:59 UTC
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.
Comment 1 Orgad Shaneh 2017-03-07 13:02:42 UTC
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
Comment 2 Orgad Shaneh 2017-03-07 15:05:24 UTC
Actually the exception should be catched in gdb_rl_callback_handler.
Comment 3 Orgad Shaneh 2017-03-07 17:18:16 UTC
Linking without -static-libstdc++ and -static-libgcc fixes this. There's a pending patch in bug 21187.
Comment 4 Joel Brobecker 2017-04-12 14:04:46 UTC
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".
Comment 5 David Engster 2017-06-13 08:18:34 UTC
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.
Comment 6 Jon Turney 2017-10-12 17:23:25 UTC
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...
Comment 7 asmwarrior 2017-10-13 06:31:15 UTC
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.
Comment 8 Jon Turney 2017-10-13 12:24:49 UTC
(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.
Comment 9 jon 2018-08-20 13:31:03 UTC
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.