[Bug gdb/30847] New: gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[Bug gdb/30847] New: gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[dbrumley at forallsecure dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

            Bug ID: 30847
           Summary: gdbtypes.c:3355: internal-error causes gdb to abort
                    when setting breakpoint
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: dbrumley at forallsecure dot com
  Target Milestone: ---

Created attachment 15110
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15110&action=edit
core file and program triggering problem.

Setting any breakpoint, even without running the program, seems to cause GDB to
crash.


GDB tells me it's a bug and to report it, so here I am :)  I didn't see any
signs it was a duplicate, but please be kind if I'm missing something obvious.



Tested on GDB version:
```
root@90f6f1dea939:/# gdb --version
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
```

GDB session.

```
root@90f6f1dea939:/# gdb /mnt/extract75-patched 
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/extract75-patched...
(gdb) break main
/build/gdb-IRllI9/gdb-13.1/gdb/gdbtypes.c:3570: internal-error:
init_complex_type: Assertion `can_create_complex_type (target_type)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0xaaaaab2c9c3b ???
0xaaaaab60bf9b ???
0xaaaaab60c183 ???
0xaaaaab7b2913 ???
0xaaaaab3f1a5f ???
0xaaaaab56a89b ???
0xaaaaab56dcef ???
0xaaaaab34491f ???
0xaaaaab34564b ???
0xaaaaab4cfdf7 ???
0xaaaaab3453e3 ???
0xaaaaab4cfdf7 ???
0xaaaaab3453e3 ???
0xaaaaab3442db ???
0xaaaaab4cd687 ???
0xaaaaab4d0bdf ???
0xaaaaab57fa23 ???
0xaaaaab596ad3 ???
0xaaaaab596d67 ???
0xaaaaab5561db ???
0xaaaaab591f9b ???
0xaaaaab596547 ???
0xaaaaab59848b ???
0xaaaaab5987bb ???
0xaaaaab33528f ???
0xaaaaab335bdf ???
0xaaaaab33520b ???
0xaaaaab43b44f ???
0xaaaaab43dd03 ???
0xaaaaab43e607 ???
0xaaaaab43e92f ???
0xaaaaab2c0f1b ???
0xaaaaab2c184b ???
0xaaaaab2f86f3 ???
0xaaaaab5cfefb ???
0xaaaaab3c3723 ???
0xaaaaab3c4bcb ???
0xaaaaab3c40b3 ???
0xffffbd9690bb ???
0xaaaaab3c41f3 ???
0xaaaaab3c4377 ???
0xaaaaab3c35f7 ???
0xaaaaab7b2da3 ???
0xaaaaab7b384b ???
0xaaaaab46adaf ???
0xaaaaab46c7d7 ???
0xaaaaab211183 ???
0xffffbc76777f __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0xffffbc767857 __libc_start_main_impl
        ../csu/libc-start.c:360
0xaaaaab2173af ???
0xffffffffffffffff ???
---------------------
/build/gdb-IRllI9/gdb-13.1/gdb/gdbtypes.c:3570: internal-error:
init_complex_type: Assertion `can_create_complex_type (target_type)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/build/gdb-IRllI9/gdb-13.1/gdb/gdbtypes.c:3570: internal-error:
init_complex_type: Assertion `can_create_complex_type (target_type)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Aborted (core dumped)

```

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Here's your problem:

murgatroyd. readelf -WS ./extract75-patched | grep stab
  [24] .stab             PROGBITS        00000000 01e100 017a0c 0c     25   0 
4
  [25] .stabstr          STRTAB          00000000 035b0c 00a713 00      0   0 
1


Stabs are extremely old and obsolete.  No one maintains them in gdb.
You should not use them.  Instead you should use the DWARF debug format.

Maybe you build with -gstabs or something -- just change that to -g and
rebuild.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[dbrumley at forallsecure dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

--- Comment #2 from David Brumley <dbrumley at forallsecure dot com> ---
Thanks for the reply!

This is an old executable and was trying to run as-is.  I have a very weird use
case. Was demo'ing exploitation (I'm a prof at CMU; demo'ing CVE-2020-13995),
and was trying to do this on the binary from the vendor.  A little more
"authentic" that way. In the grand scheme of things this is odd, and reported
because gdb said to and I was curious if it could be used for anti-debugging.
Totally fair to close this issue since I can't see this happening in any normal
dev scenario.

For completeness:

* The binary is from an old redhat system with an old `glibc` where `errno`
works different (pre pthread?).
* It failed to run initially with
`extract75: symbol lookup error: ./extract75: undefined symbol: errno, version
GLIBC_2.0`
* I edited the binary to run (and it runs fine) by changing the errno symbol to
point to stdin. 

I thought the symbol editing might be the source of the problem.  I recompiled
gdb on my debian system with symbols, and here is the symbol bt in case it's
useful.  I'm not seeing anything specific to stabs, but I'm also a total newb
here and don't know anything really.

Again, feel free to close if uninteresting.

```
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f2a32386537 in __GI_abort () at abort.c:79
During symbol reading: incomplete CFI data; unspecified registers (e.g., rax)
at 0x5652ee9bc49d
#2  0x00005652ee9bc4c7 in dump_core () at utils.c:204
#3  0x00005652ee9bca14 in internal_vproblem(internal_problem *, const char *,
int, const char *, typedef __va_list_tag __va_list_tag *) (
    problem=0x5652eefb7000 <internal_error_problem>, file=0x5652eebf4abd
"gdbtypes.c", 
    line=3355, fmt=0x5652eebf4769 "%s: Assertion `%s' failed.",
ap=0x7ffe37252ec8)
    at utils.c:414
#4  0x00005652ee9bcada in internal_verror (file=0x5652eebf4abd "gdbtypes.c",
line=3355, 
    fmt=0x5652eebf4769 "%s: Assertion `%s' failed.", ap=0x7ffe37252ec8) at
utils.c:439
#5  0x00005652eeb427af in internal_error (file=0x5652eebf4abd "gdbtypes.c",
line=3355, 
    fmt=0x5652eebf4769 "%s: Assertion `%s' failed.") at errors.cc:55
#6  0x00005652ee6c933c in init_complex_type (name=0x0,
target_type=0x5652f021e600)
    at gdbtypes.c:3355
#7  0x00005652ee8ec69f in read_range_type (pp=0x7ffe37253298,
typenums=0x7ffe372530d8, 
    type_size=-1, objfile=0x5652f01a2c40) at stabsread.c:4064
#8  0x00005652ee8e74e0 in read_type (pp=0x7ffe37253298, objfile=0x5652f01a2c40)
    at stabsread.c:1932
#9  0x00005652ee8e562f in define_symbol (valu=0x0, 
    string=0x5652f01de7d3 "complex double:t(0,17)=r(0,17);16;0;", desc=0,
type=128, 
    objfile=0x5652f01a2c40) at stabsread.c:1205
#10 0x00005652ee5ba59a in process_one_symbol (type=128, desc=0, valu=0x0, 
    name=0x5652f01de7d3 "complex double:t(0,17)=r(0,17);16;0;", 
    section_offsets=std::vector of length 31, capacity 31 = {...},
objfile=0x5652f01a2c40, language=language_c) at dbxread.c:2789
#11 0x00005652ee5b961a in read_ofile_symtab (objfile=0x5652f01a2c40,
pst=0x5652f01dbf50) at dbxread.c:2233
#12 0x00005652ee5b8f59 in dbx_expand_psymtab (pst=0x5652f01dbf50,
objfile=0x5652f01a2c40) at dbxread.c:2083
#13 0x00005652ee5bbb40 in legacy_psymtab::expand_psymtab (this=0x5652f01dbf50,
objf=0x5652f01a2c40) at psympriv.h:371
#14 0x00005652ee81723a in partial_symtab::expand_dependencies
(this=0x5652f01ceeb0, objfile=0x5652f01a2c40) at psymtab.c:1731
#15 0x00005652ee5b8eea in dbx_expand_psymtab (pst=0x5652f01ceeb0,
objfile=0x5652f01a2c40) at dbxread.c:2071
#16 0x00005652ee5bbb40 in legacy_psymtab::expand_psymtab (this=0x5652f01ceeb0,
objf=0x5652f01a2c40) at psympriv.h:371
#17 0x00005652ee81723a in partial_symtab::expand_dependencies
(this=0x5652f01f2f00, objfile=0x5652f01a2c40) at psymtab.c:1731
#18 0x00005652ee5b8eea in dbx_expand_psymtab (pst=0x5652f01f2f00,
objfile=0x5652f01a2c40) at dbxread.c:2071
#19 0x00005652ee5bbb40 in legacy_psymtab::expand_psymtab (this=0x5652f01f2f00,
objf=0x5652f01a2c40) at psympriv.h:371
#20 0x00005652ee5b90b8 in dbx_read_symtab (self=0x5652f01f2f00,
objfile=0x5652f01a2c40) at dbxread.c:2113
#21 0x00005652ee5bbb15 in legacy_psymtab::read_symtab (this=0x5652f01f2f00,
objf=0x5652f01a2c40) at psympriv.h:366
#22 0x00005652ee8146b4 in psymtab_to_symtab (objfile=0x5652f01a2c40,
pst=0x5652f01f2f00) at psymtab.c:766
#23 0x00005652ee813bb4 in psym_lookup_symbol (objfile=0x5652f01a2c40,
block_index=GLOBAL_BLOCK, name=0x7ffe37253f70 "main", domain=VAR_DOMAIN) at
psymtab.c:493
#24 0x00005652ee91a38f in lookup_symbol_via_quick_fns (objfile=0x5652f01a2c40,
block_index=GLOBAL_BLOCK, name=0x7ffe37253f70 "main", domain=VAR_DOMAIN) at
symtab.c:2373
#25 0x00005652ee91a7ef in lookup_symbol_in_objfile (During symbol reading:
Child DIE 0x25597a5 and its abstract origin 0x255ec59 have different parents
objfile=0x5652f01a2c40, block_index=GLOBAL_BLOCK, name=0x7ffe37253f70 "main",
domain=VAR_DOMAIN) at symtab.c:2522
#26 0x00005652ee91aa73 in lookup_symbol_global_or_static_iterator_cb
(objfile=0x5652f01a2c40, cb_data=0x7ffe37253d40) at symtab.c:2596
#27 0x00005652ee8d04d0 in svr4_iterate_over_objfiles_in_search_order
(gdbarch=0x5652f0172dd0, cb=0x5652ee91a9e8
<lookup_symbol_global_or_static_iterator_cb(objfile*, void*)>,
cb_data=0x7ffe37253d40, current_objfile=0x0) at solib-svr4.c:3248
#28 0x00005652ee6bec94 in gdbarch_iterate_over_objfiles_in_search_order
(gdbarch=0x5652f0172dd0, cb=0x5652ee91a9e8
<lookup_symbol_global_or_static_iterator_cb(objfile*, void*)>,
cb_data=0x7ffe37253d40, current_objfile=0x0) at gdbarch.c:4868
#29 0x00005652ee91ac01 in lookup_global_or_static_symbol (name=0x7ffe37253f70
"main", block_index=GLOBAL_BLOCK, objfile=0x0, domain=VAR_DOMAIN) at
symtab.c:2641
#30 0x00005652ee91ad70 in lookup_global_symbol (name=0x7ffe37253f70 "main",
block=0x0, domain=VAR_DOMAIN) at symtab.c:2692
#31 0x00005652ee91a568 in language_defn::lookup_symbol_nonlocal
(this=0x5652eefc57e0 <c_language_defn>, name=0x7ffe37253f70 "main", block=0x0,
domain=VAR_DOMAIN) at symtab.c:2442
#32 0x00005652ee919929 in lookup_symbol_aux (name=0x7ffe37253f70 "main",
match_type=symbol_name_match_type::FULL, block=0x0, domain=VAR_DOMAIN,
language=language_c, is_a_field_of_this=0x0) at symtab.c:2089
#33 0x00005652ee9190f8 in lookup_symbol_in_language (name=0x7ffe37253f70
"main", block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0)
at symtab.c:1884
#34 0x00005652ee919172 in lookup_symbol (name=0x7ffe37253f70 "main", block=0x0,
domain=VAR_DOMAIN, is_a_field_of_this=0x0) at symtab.c:1896
#35 0x00005652ee5a192a in inspect_type (info=0x5652f01d0e00,
ret_comp=0x5652effec990, finder=0x0, data=0x0) at cp-support.c:160
#36 0x00005652ee5a2573 in replace_typedefs (info=0x5652f01d0e00,
ret_comp=0x5652effec990, finder=0x0, data=0x0) at cp-support.c:544
#37 0x00005652ee5a26ca in cp_canonicalize_string_full (During symbol reading:
.debug_line address at offset 0x1d81f9 is 0 [in module /usr/src/gdb/gdb/gdb]
string=0x5652f01d0fc0 "main", finder=0x0, data=0x0) at cp-support.c:595
#38 0x00005652ee5a280a in cp_canonicalize_string_no_typedefs
(string=0x5652f01d0fc0 "main") at cp-support.c:619
#39 0x00005652ee741a69 in find_linespec_symbols (state=0x7ffe372546c0,
file_symtabs=0x5652f01d0e70, lookup_name=0x5652f01d0fc0 "main",
name_match_type=symbol_name_match_type::WILD, symbols=0x7ffe37254340,
minsyms=0x7ffe37254320) at linespec.c:3902
#40 0x00005652ee73c112 in linespec_parse_basic (parser=0x7ffe37254690) at
linespec.c:1866
#41 0x00005652ee73e53e in parse_linespec (parser=0x7ffe37254690,
arg=0x5652f01d0d60 "main", match_type=symbol_name_match_type::WILD) at
linespec.c:2655
#42 0x00005652ee73f97d in event_location_to_sals (parser=0x7ffe37254690,
location=0x5652f01d0d20) at linespec.c:3151
#43 0x00005652ee73fd81 in decode_line_full (location=0x5652f01d0d20, flags=1,
search_pspace=0x0, default_symtab=0x0, default_line=0,
canonical=0x7ffe37254ac0, select_mode=0x0, filter=0x0) at linespec.c:3230
#44 0x00005652ee4da613 in parse_breakpoint_sals (location=0x5652f01d0d20,
canonical=0x7ffe37254ac0) at breakpoint.c:9037
#45 0x00005652ee4e59f1 in create_sals_from_location_default
(location=0x5652f01d0d20, canonical=0x7ffe37254ac0, type_wanted=bp_breakpoint)
at breakpoint.c:13733
#46 0x00005652ee4e2e80 in bkpt_create_sals_from_location
(location=0x5652f01d0d20, canonical=0x7ffe37254ac0, type_wanted=bp_breakpoint)
at breakpoint.c:12534
#47 0x00005652ee4daf23 in create_breakpoint (gdbarch=0x5652f0172dd0,
location=0x5652f01d0d20, cond_string=0x0, thread=0, extra_string=0x0,
parse_extra=1, tempflag=0, type_wanted=bp_breakpoint, ignore_count=0,
pending_break_support=AUTO_BOOLEAN_AUTO, ops=0x5652eefc4380
<bkpt_breakpoint_ops>, from_tty=1, enabled=1, internal=0, flags=0) at
breakpoint.c:9253
#48 0x00005652ee4db77f in break_command_1 (arg=0x5652effec74a "", flag=0,
from_tty=1) at breakpoint.c:9411
#49 0x00005652ee4dba68 in break_command (arg=0x5652effec746 "main", from_tty=1)
at breakpoint.c:9482
#50 0x00005652ee5434c2 in do_const_cfunc (c=0x5652f00e5ee0, args=0x5652effec746
"main", from_tty=1) at cli/cli-decode.c:95
#51 0x00005652ee546c16 in cmd_func (cmd=0x5652f00e5ee0, args=0x5652effec746
"main", from_tty=1) at cli/cli-decode.c:2181
#52 0x00005652ee96c110 in execute_command (p=0x5652effec749 "n", from_tty=1) at
top.c:668
#53 0x00005652ee68afe5 in command_handler (command=0x5652effec740 "break main")
at event-top.c:588
#54 0x00005652ee68b420 in command_line_handler (rl=...) at event-top.c:773
#55 0x00005652ee68a7d1 in gdb_rl_callback_handler (rl=0x5652f01dbfe0 "break
main") at event-top.c:219
#56 0x00005652eea1ec79 in rl_callback_read_char () at callback.c:281
#57 0x00005652ee68a641 in gdb_rl_callback_read_char_wrapper_noexcept () at
event-top.c:177
#58 0x00005652ee68a6c8 in gdb_rl_callback_read_char_wrapper
(client_data=0x5652effeb670) at event-top.c:194
#59 0x00005652ee68ae87 in stdin_event_handler (error=0,
client_data=0x5652effeb670) at event-top.c:516
#60 0x00005652eeb434ca in handle_file_event (file_ptr=0x5652f0182560,
ready_mask=1) at event-loop.cc:548
#61 0x00005652eeb43a65 in gdb_wait_for_event (block=1) at event-loop.cc:673
#62 0x00005652eeb42962 in gdb_do_one_event () at event-loop.cc:215
#63 0x00005652ee78017b in start_event_loop () at main.c:356
#64 0x00005652ee78029c in captured_command_loop () at main.c:416
#65 0x00005652ee7819e3 in captured_main (data=0x7ffe37255230) at main.c:1253
#66 0x00005652ee781a49 in gdb_main (args=0x7ffe37255230) at main.c:1268
#67 0x00005652ee44d75f in main (argc=2, argv=0x7ffe37255348) at gdb.c:32
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to David Brumley from comment #2)
> Thanks for the reply!

No problem, & thank you too.

> This is an old executable and was trying to run as-is.  I have a very weird
> use case. Was demo'ing exploitation (I'm a prof at CMU; demo'ing
> CVE-2020-13995), and was trying to do this on the binary from the vendor.  A
> little more "authentic" that way. In the grand scheme of things this is odd,
> and reported because gdb said to and I was curious if it could be used for
> anti-debugging. Totally fair to close this issue since I can't see this
> happening in any normal dev scenario.

Well, I'm curious to know more about your situation.
We're debating whether to remove stabs support entirely from gdb.
I'm pro-deletion, since it has been obsolete since "forever" (20 years)
and since nobody knows or works on the stabs code -- as you can see
this has resulted in bit-rot.

However, there are others asking that it be kept alive.

One question I have is why you tried a newer gdb rather than an
older one.  But maybe you already answered -- I guess that you
have a new machine but an old executable.

> * I edited the binary to run (and it runs fine) by changing the errno symbol
> to point to stdin. 

Wow.

> I thought the symbol editing might be the source of the problem.  I
> recompiled gdb on my debian system with symbols, and here is the symbol bt
> in case it's useful.  I'm not seeing anything specific to stabs, but I'm
> also a total newb here and don't know anything really.
> 

> #9  0x00005652ee8e562f in define_symbol (valu=0x0, 
>     string=0x5652f01de7d3 "complex double:t(0,17)=r(0,17);16;0;", desc=0,
> type=128, 
>     objfile=0x5652f01a2c40) at stabsread.c:1205

Any stack trace through stabsread.c means you do have stabs.
You can double-check with "readelf -WS" and look for the stabstr section.

You can check your build logs to see what debug flags were used.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I totally misread that as you rebuilding your program --
but you rebuilt gdb (which you said...).
Sorry about that.  Anyway this bug is probably not hard
to fix, and the backtrace is handy for diagnosing w/o sources.
So, thank you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[dbrumley at forallsecure dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

--- Comment #5 from David Brumley <dbrumley at forallsecure dot com> ---
Hi,

First, thank you for helping me understand the issue.  Your deep knowledge and
fast response times to something as weird as my bug report are much
appreciated.

I felt you might be interested in the lecture, and not sure that was useful for
the list.

Here are my slides, with the particular CVE starting on page 21:
https://docs.google.com/presentation/d/1z_XJWrHgoJrmVcJQHCKth_lx0Olz39e-VXC_tW9imfk/

* I'm a big believer in the growth mindset, so if you happen to look and see
something wrong, please let me know! It's how I get better!

* As you can see, I ended up building from source code anyway.

Editing the symbol table was pretty easy.  I've done it manually in the past,
but I found a very nice library called lief recently.

import lief
binary = lief.parse('extract75')
errno = next(filter(lambda e: e.name ( http://e.name/ ) == "errno",
binary.symbols))
stdin = next(filter(lambda e: e.name ( http://e.name/ ) == "stdin",
binary.symbols))
errno.name ( http://errno.name/ ) = stdin.name ( http://stdin.name/ )
binary.write('extract75-hacked')

Thanks again!

Best wishes,

David

Dr. David Brumley

CEO
Executive Assistant: Teressa Peirona < teressa@forallsecure.com >

On Wed, Sep 20, 2023 at 7:07 PM, tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org > wrote:

> 
> 
> 
> https:/ / sourceware. org/ bugzilla/ show_bug. cgi?id=30847 (
> https://sourceware.org/bugzilla/show_bug.cgi?id=30847 )
> 
> 
> 
> --- Comment #4 from Tom Tromey <tromey at sourceware dot org> --- I
> totally misread that as you rebuilding your program -- but you rebuilt gdb
> (which you said...).
> Sorry about that. Anyway this bug is probably not hard to fix, and the
> backtrace is handy for diagnosing w/o sources. So, thank you.
> 
> 
> 
> --
> You are receiving this mail because:
> You reported the bug.
> 
> 
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[dbrumley at forallsecure dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

--- Comment #6 from David Brumley <dbrumley at forallsecure dot com> ---
I didn't answer the stab question; apologies.

I don't have a super strong opinion here. Older binaries are pretty prevalent
in cyber-physical systems (airplanes, power, etc) since the system deployment
timeline is often decades. It's always nice if the latest gdb just works, and I
think relevant to the sysadmin or security trying to diagnose issues.  Those
same people typically don't have source.

It's totally reasonable to deprioritize and just recommend they use an older
gdb. It's a question, at least to me, of how much the focus is on the developer
vs. users of compiled code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30847

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
I think the story here is that nobody who works on gdb
either knows or maintains the stabs code.  If someone
were to send patches to fix problems, we'd apply them.
In the absence of that, we may remove all stabs support.

-- 
You are receiving this mail because:
You are on the CC list for the bug.