hi, a large c++ enum-class crashes gdb during variable printing. (gdb) r Starting program: /home/pawels/src/bugs/gdb-big-enum/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main () at test.cpp:5 5 enumVal = ENUM_ID::ENUM_VAL_14; (gdb) n 6 return 0; (gdb) p enumVal $1 = gdbtypes.h:985: internal-error: field: Assertion `idx >= 0 && idx < num_fields ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x56522c4cabf0 gdb_internal_backtrace_1 /home/pawels/src/binutils-gdb/gdb/bt-utils.c:122 0x56522c4cabf0 _Z22gdb_internal_backtracev /home/pawels/src/binutils-gdb/gdb/bt-utils.c:168 0x56522c88a564 internal_vproblem /home/pawels/src/binutils-gdb/gdb/utils.c:396 0x56522c88a820 _Z15internal_verrorPKciS0_P13__va_list_tag /home/pawels/src/binutils-gdb/gdb/utils.c:476 0x56522c9d6d34 _Z18internal_error_locPKciS0_z /home/pawels/src/binutils-gdb/gdbsupport/errors.cc:58 0x56522c89a6d2 _ZNK4type5fieldEi /home/pawels/src/binutils-gdb/gdb/gdbtypes.h:985 0x56522c89a6d2 _ZNK4type5fieldEi /home/pawels/src/binutils-gdb/gdb/gdbtypes.h:983 0x56522c89a6d2 generic_val_print_enum_1 /home/pawels/src/binutils-gdb/gdb/valprint.c:657 0x56522c89b3ca _Z16common_val_printP5valueP7ui_fileiPK19value_print_optionsPK13language_defn /home/pawels/src/binutils-gdb/gdb/valprint.c:1073 0x56522c4ef9d0 _Z13c_value_printP5valueP7ui_filePK19value_print_options /home/pawels/src/binutils-gdb/gdb/c-valprint.c:588 0x56522c89b572 _Z11value_printP5valueP7ui_filePK19value_print_options /home/pawels/src/binutils-gdb/gdb/valprint.c:1190 0x56522c72e334 _Z11print_valueP5valueRK19value_print_options /home/pawels/src/binutils-gdb/gdb/printcmd.c:1252 0x56522c72e5c2 print_command_1 /home/pawels/src/binutils-gdb/gdb/printcmd.c:1361 0x56522c4ff1e4 _Z8cmd_funcP16cmd_list_elementPKci cli/cli-decode.c:2543 0x56522c820ad1 _Z15execute_commandPKci /home/pawels/src/binutils-gdb/gdb/top.c:688 0x56522c5ef524 _Z15command_handlerPKc /home/pawels/src/binutils-gdb/gdb/event-top.c:616 0x56522c5f0833 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE /home/pawels/src/binutils-gdb/gdb/event-top.c:852 0x56522c5eff7c gdb_rl_callback_handler /home/pawels/src/binutils-gdb/gdb/event-top.c:246 0x56522c8ccdd7 rl_callback_read_char /home/pawels/src/binutils-gdb/readline/readline/callback.c:290 0x56522c5eefbd gdb_rl_callback_read_char_wrapper_noexcept /home/pawels/src/binutils-gdb/gdb/event-top.c:188 0x56522c5efe33 gdb_rl_callback_read_char_wrapper /home/pawels/src/binutils-gdb/gdb/event-top.c:221 0x56522c5ee9af stdin_event_handler /home/pawels/src/binutils-gdb/gdb/event-top.c:541 0x56522c9d7495 gdb_wait_for_event /home/pawels/src/binutils-gdb/gdbsupport/event-loop.cc:694 0x56522c9d7eb5 gdb_wait_for_event /home/pawels/src/binutils-gdb/gdbsupport/event-loop.cc:593 0x56522c9d7eb5 _Z16gdb_do_one_eventi /home/pawels/src/binutils-gdb/gdbsupport/event-loop.cc:264 0x56522c6cb8e9 start_event_loop /home/pawels/src/binutils-gdb/gdb/main.c:411 0x56522c6cb8e9 captured_command_loop /home/pawels/src/binutils-gdb/gdb/main.c:471 0x56522c6cd484 captured_main /home/pawels/src/binutils-gdb/gdb/main.c:1310 0x56522c6cd484 _Z8gdb_mainP18captured_main_args /home/pawels/src/binutils-gdb/gdb/main.c:1325 0x56522c41bb7f main /home/pawels/src/binutils-gdb/gdb/gdb.c:32 --------------------- gdbtypes.h:985: internal-error: field: Assertion `idx >= 0 && idx < num_fields ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable.
Created attachment 14570 [details] testcase
looks like, fine tuned 'short nfields' (gdbtypes.h:839) is not enough for such testcase. lldb works fine.
I feel like we've been waiting for years for this to bite. Hilariously I think this test case would work with 'unsigned short', but at the same time, surely someone out there wants an enum with 65537 constants.
Is this a real program (presumably auto generated code), or just some toolchain testcase or some such? "ENUM_ID::ENUM_VAL_14" kind of hints at the latter.
(In reply to Pedro Alves from comment #4) > Is this a real program (presumably auto generated code), or just some > toolchain testcase or some such? "ENUM_ID::ENUM_VAL_14" kind of hints at > the latter. original program is a real hdl compiler for complex fpga technology. testcase is reduced and anonymized to ENUM_VAL_*. one way or another, assigning 'int idx' to 'short' will not work forever...
https://sourceware.org/pipermail/gdb-patches/2023-January/195572.html That allows about 2 billion constants on typical arches. We could boost it higher if we cared to.
Sent v2.
> original program is a real hdl compiler for complex fpga technology. testcase > is reduced and anonymized to ENUM_VAL_*. one way or another, assigning 'int > idx' to 'short' will not work forever... Thanks. I was asking because I had the impression that GCC dropped debug info once some limit is reached or some such. Turns out it's worse than that -- it fails to compile, as Tromey discovered while writing a testcase. So I guess you must be using Clang or some other compiler.
(In reply to Pedro Alves from comment #8) > Thanks. I was asking because I had the impression that GCC dropped debug > info once some limit is reached or some such. Turns out it's worse than > that -- it fails to compile, as Tromey discovered while writing a testcase. > So I guess you must be using Clang or some other compiler. Actually it turned out that the supplied test does work in gcc, but when I wrote one for the test suite I used a larger constant and that caused a failure.
(In reply to Pedro Alves from comment #8) > > original program is a real hdl compiler for complex fpga technology. testcase > > is reduced and anonymized to ENUM_VAL_*. one way or another, assigning 'int > > idx' to 'short' will not work forever... > > Thanks. I was asking because I had the impression that GCC dropped debug > info once some limit is reached or some such. Turns out it's worse than > that -- it fails to compile, as Tromey discovered while writing a testcase. > So I guess you must be using Clang or some other compiler. yes, we're currently using clang-15 (compiler/tools/thinlto/lld) + libcxx.llvm.org + qtcreator-9.x + gdb for development and local (x86_64)/remote(x86_64->arm64) debugging.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1775f8b3804744c22611ed0c9fd2df4f5b4d8641 commit 1775f8b3804744c22611ed0c9fd2df4f5b4d8641 Author: Tom Tromey <tromey@adacore.com> Date: Wed Jan 11 12:42:40 2023 -0700 Increase size of main_type::nfields main_type::nfields is a 'short', and has been for many years. PR c++/29985 points out that 'short' is too narrow for an enum that contains more than 2^15 constants. This patch bumps the size of 'nfields'. To verify that the field isn't directly used, it is also renamed. Note that this does not affect the size of main_type on x86-64 Fedora 36. And, if it does have a negative effect somewhere, it's worth considering that types could be shrunk more drastically by using subclasses for the different codes. This is v2 of this patch, which has these changes: * I changed nfields to 'unsigned', per Simon's request. I looked at changing all the uses, but this quickly fans out into a very large patch. (One additional tweak was needed, though.) * I wrote a test case. I discovered that GCC cannot compile a large enough C test case, so I resorted to using the DWARF assembler. This test doesn't reproduce the crash, but it does fail without the patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29985
Fixed.
*** Bug 30236 has been marked as a duplicate of this bug. ***