[Bug mi/32571] New: GDB Mi crashes when setting a disabled breakpoint

[Bug mi/32571] New: GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

            Bug ID: 32571
           Summary: GDB Mi crashes when setting a disabled breakpoint
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: mi
          Assignee: unassigned at sourceware dot org
          Reporter: jarmo.tiitto at gmail dot com
  Target Milestone: ---

"gdb --interpreter=mi2 -quiet" (GDB 15.2) can crash to an apparrent heap
corruption with following input:

-gdb-show version
-gdb-set width 0
-gdb-set height 0
handle SIG32 pass nostop
handle SIG41 pass nostop
handle SIG42 pass nostop
handle SIG43 pass nostop
-enable-pretty-printing
-gdb-set charset UTF-8
-gdb-set print sevenbit-strings off
python sys.path.insert(0, "/mnt/source/kde6/usr/share/kdevgdb/printers")
source /mnt/source/kde6/usr/share/kdevgdb/printers/gdbinit
-gdb-set disable-randomization off
-gdb-set print static-members off
-gdb-set print asm-demangle on
-environment-cd "/mnt/source/slot_map/build"
-file-exec-and-symbols /mnt/source/slot_map/build/radix_sort
-break-insert -f "/mnt/source/slot_map/paged_byte_fifo.cpp:127"
-break-insert -f "/mnt/source/slot_map/radixsort.cpp:201"
-break-insert -f "/mnt/source/slot_map/radixsort.cpp:118"
-break-insert -f "/mnt/source/slot_map/radixsort.cpp:141"
-break-insert -f "/mnt/source/slot_map/radixsort.cpp:177"
-break-insert -f -d "/mnt/source/slot_map/paged_byte_fifo.cpp:132"
-break-insert -f "/mnt/source/slot_map/paged_byte_fifo.cpp:137"
-break-insert -f -d "/mnt/source/slot_map/paged_byte_fifo.cpp:141"
-break-insert -f "/mnt/source/slot_map/paged_byte_fifo.cpp:146"
-break-insert -f -d "/mnt/source/slot_map/paged_byte_fifo.cpp:26"

The bug affects KDevelop's debugger with GDB 15.2, and the triggering factor
seems to be setting a disabled breakpoint in a function which is optimized out.
(i.e. no code gets generated for it) I can provide above files, if needed, or
perhaps try figure out an simpler reproducer.

The core file is unfortunately over 10MiB (compressed), so here is at least
backtrace of it:
0  __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff6f88463 in __pthread_kill_internal (threadid=<optimized out>,
signo=6) at pthread_kill.c:78
#2  0x00007ffff6f2f120 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3  0x00007ffff6f164c3 in __GI_abort () at abort.c:79
#4  0x00007ffff6f17354 in __libc_message_impl (fmt=fmt@entry=0x7ffff70a52f5
"%s\n") at ../sysdeps/posix/libc_fatal.c:132
#5  0x00007ffff6f92765 in malloc_printerr (str=str@entry=0x7ffff70a3015
"corrupted double-linked list") at malloc.c:5772
#6  0x00007ffff6f9338c in unlink_chunk (p=p@entry=0x555557560120,
av=0x7ffff70d9ac0 <main_arena>) at malloc.c:1617
#7  0x00007ffff6f9625a in _int_malloc (av=av@entry=0x7ffff70d9ac0 <main_arena>,
bytes=bytes@entry=56) at malloc.c:4381
#8  0x00007ffff6f97fae in __libc_calloc (n=n@entry=7,
elem_size=elem_size@entry=8) at malloc.c:3754
#9  0x000055555606a9fc in xcalloc (number=7, size=8) at ../../gdb/alloc.c:92
#10 htab_create_typed_alloc (size=7, hash_f=0x5555560506c0 <hash_pointer(void
const*)>, eq_f=0x555556050670 <eq_pointer(void const*, void const*)>,
del_f=0x0, alloc_tab_f=<optimized out>, alloc_f=<optimized out>,
free_f=<optimized out>)
    at ../libiberty/../../libiberty/hashtab.c:360
#11 htab_create_alloc (size=<optimized out>, hash_f=0x5555560506c0
<hash_pointer(void const*)>, eq_f=0x555556050670 <eq_pointer(void const*, void
const*)>, del_f=0x0, alloc_f=<optimized out>, free_f=<optimized out>)
    at ../libiberty/../../libiberty/hashtab.c:285
#12 htab_create (size=<optimized out>, hash_f=0x5555560506c0 <hash_pointer(void
const*)>, eq_f=0x555556050670 <eq_pointer(void const*, void const*)>,
del_f=0x0) at ../libiberty/../../libiberty/hashtab.c:399
#13 0x00005555558f98b1 in (anonymous
namespace)::symtab_collector::symtab_collector (this=0x7fffffffd620) at
../../gdb/linespec.c:3652
#14 collect_symtabs_from_filename (file=file@entry=0x555557836a60
"/mnt/source/slot_map/paged_byte_fifo.cpp", search_pspace=0x0) at
../../gdb/linespec.c:3699
#15 0x00005555558f99f7 in symtabs_from_filename
(filename=filename@entry=0x555557836a60
"/mnt/source/slot_map/paged_byte_fifo.cpp", search_pspace=<optimized out>) at
../../gdb/linespec.c:3729
#16 0x000055555590952d in parse_linespec (parser=parser@entry=0x7fffffffdbe0,
arg=<optimized out>, match_type=<optimized out>) at ../../gdb/linespec.c:2558
#17 0x000055555590aaeb in location_spec_to_sals (parser=0x7fffffffdbe0,
locspec=0x555557778700) at ../../gdb/linespec.c:3079
#18 0x00005555560bc524 in decode_line_full(location_spec*, int, program_space*,
symtab*, int, linespec_result*, char const*, char const*) [clone .constprop.0]
(locspec=locspec@entry=0x555557778700, search_pspace=search_pspace@entry=0x0, 
    default_symtab=default_symtab@entry=0x0, default_line=<optimized out>,
canonical=canonical@entry=0x7fffffffdf40, select_mode=select_mode@entry=0x0,
filter=<optimized out>, flags=1) at ../../gdb/linespec.c:3156
#19 0x00005555556dad82 in parse_breakpoint_sals (locspec=0x555557778700,
canonical=0x7fffffffdf40) at ../../gdb/breakpoint.c:8899
#20 0x00005555556e3395 in create_breakpoint (gdbarch=0x5555576f4780,
locspec=0x555557778700, cond_string=0x0, thread=<optimized out>,
inferior=<optimized out>, extra_string=<optimized out>, force_condition=false,
parse_extra=0, 
    tempflag=0, type_wanted=bp_breakpoint, ignore_count=0,
pending_break_support=AUTO_BOOLEAN_TRUE, ops=0x5555566e3b90
<code_breakpoint_ops>, from_tty=0, enabled=0, internal=0, flags=0) at
../../gdb/breakpoint.c:9250
#21 0x000055555611977f in mi_cmd_break_insert_1(int, char const*, char const*
const*, int) [clone .isra.0] (dprintf=<optimized out>, argv=<optimized out>,
argc=<optimized out>, command=<optimized out>) at
../../gdb/mi/mi-cmd-break.c:368
#22 0x0000555555984773 in mi_cmd_execute (parse=parse@entry=0x555557782560) at
../../gdb/mi/mi-main.c:2148
#23 0x0000555555985cad in captured_mi_execute_command (mi=0x55555757eef0,
uiout=0x55555768fd70, context=0x555557782560) at ../../gdb/mi/mi-main.c:1831
#24 mi_execute_command (cmd=<optimized out>, from_tty=<optimized out>) at
../../gdb/mi/mi-main.c:1955
#25 0x0000555555986194 in mi_execute_command_wrapper (cmd=<optimized out>) at
../../gdb/mi/mi-interp.c:219
#26 mi_execute_command_input_handler (cmd=...) at ../../gdb/mi/mi-interp.c:241
#27 0x00005555558135f7 in gdb_readline_no_editing_callback
(client_data=<optimized out>) at ../../gdb/event-top.c:873
#28 0x0000555555be9740 in stdin_event_handler (error=<optimized out>,
client_data=0x5555572a3560) at ../../gdb/ui.c:154
#29 0x000055555607f3e1 in gdb_wait_for_event (block=<optimized out>) at
../gdbsupport/../../gdbsupport/event-loop.cc:694
#30 0x00005555560ce703 in gdb_do_one_event(int) [clone .constprop.0]
(mstimeout=<optimized out>) at ../gdbsupport/../../gdbsupport/event-loop.cc:263
#31 0x0000555555952765 in start_event_loop () at ../../gdb/main.c:400
#32 captured_command_loop () at ../../gdb/main.c:464
#33 0x00005555555ebc15 in captured_main (data=0x7fffffffe6c0) at
../../gdb/main.c:1337
#34 gdb_main (args=0x7fffffffe6c0) at ../../gdb/main.c:1356
#35 main (argc=3, argv=0x7fffffffe818) at ../../gdb/gdb.c:38

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[tromey at sourceware dot org]

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

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> ---
I wonder if you could run gdb under valgrind and see what it reports.
Unfortunately the stack trace isn't very suggestive.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

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

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

--- Comment #2 from Jarmo Tiitto <jarmo.tiitto at gmail dot com> ---
Created attachment 15892
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15892&action=edit
valgrind output

I now ran

valgrind --log-file=valgrind_gdb.txt --leak-check=full --track-origins=yes gdb
gdb --interpreter=mi2 -quiet

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[aburgess at redhat dot com]

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

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com

--- Comment #3 from Andrew Burgess <aburgess at redhat dot com> ---
Jarmo,

If it's not too large, and it's possible to, then could you share the test
executable please.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

--- Comment #4 from Jarmo Tiitto <jarmo.tiitto at gmail dot com> ---
Created attachment 15893
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15893&action=edit
environment to reproduce the crash

(In reply to Andrew Burgess from comment #3)
> Jarmo,
> 
> If it's not too large, and it's possible to, then could you share the test
> executable please.

I attached an another project in which gdb crashes in the same way, and I
managed to trim this down to a somewhat minimal reproducer.tar.gz archive. The
executable is built in RelWithDebInfo mode, and is included in the archive.

"cat gdbmicmdlist.txt | gdb --interpreter=mi2 -quiet"

This time I get an crash at the second breakpoint command.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

--- Comment #5 from Jarmo Tiitto <jarmo.tiitto at gmail dot com> ---
I think I found a major factor of why gdb crashes: with enough enviroment
variables set, the crash will take place. This required about 58 "export
VAR0="blah1 blah2 blah3" to be set before running the reproducer.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[ssbssa at sourceware dot org]

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

--- Comment #6 from Hannes Domani <ssbssa at sourceware dot org> ---
The seems to be the interesting part of the valgrind log:

> Invalid read of size 8
>    at 0x3CBDA9: UnknownInlinedFun (basic_string.h:228)
>    by 0x3CBDA9: UnknownInlinedFun (basic_string.h:2641)
>    by 0x3CBDA9: UnknownInlinedFun (common-exceptions.h:171)
>    by 0x3CBDA9: print_exception(ui_file*, gdb_exception const&) [clone .lto_priv.0] (exceptions.c:75)
>    by 0x1543E7: create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) [clone .cold] (breakpoint.c:9264)
>    by 0xCCD77E: mi_cmd_break_insert_1(int, char const*, char const* const*, int) [clone .isra.0] (mi-cmd-break.c:368)
>    by 0x538772: mi_cmd_execute(mi_parse*) (mi-main.c:2148)
>    by 0x539CAC: UnknownInlinedFun (mi-main.c:1831)
>    by 0x539CAC: mi_execute_command(char const*, int) (mi-main.c:1955)
>    by 0x53A193: UnknownInlinedFun (mi-interp.c:219)
>    by 0x53A193: mi_execute_command_input_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (mi-interp.c:241)
>    by 0x3C75F6: gdb_readline_no_editing_callback(void*) (event-top.c:873)
>    by 0x79D73F: stdin_event_handler(int, void*) (ui.c:154)
>    by 0xC333E0: gdb_wait_for_event(int) [clone .lto_priv.0] (event-loop.cc:694)
>    by 0xC826CE: gdb_do_one_event(int) [clone .constprop.0] (event-loop.cc:216)
>    by 0x506764: UnknownInlinedFun (main.c:400)
>    by 0x506764: captured_command_loop() [clone .lto_priv.0] (main.c:464)
>    by 0x19FC14: UnknownInlinedFun (main.c:1337)
>    by 0x19FC14: UnknownInlinedFun (main.c:1356)
>    by 0x19FC14: main (gdb.c:38)
>  Address 0xcf35db0 is 16 bytes inside a block of size 48 free'd
>    at 0x48478EF: free (vg_replace_malloc.c:989)
>    by 0x16FAFE: UnknownInlinedFun (shared_ptr_base.h:1069)
>    by 0x16FAFE: UnknownInlinedFun (shared_ptr_base.h:1525)
>    by 0x16FAFE: UnknownInlinedFun (shared_ptr.h:175)
>    by 0x16FAFE: UnknownInlinedFun (common-exceptions.h:119)
>    by 0x16FAFE: parse_linespec(linespec_parser*, char const*, symbol_name_match_type) [clone .cold] (linespec.c:2642)
>    by 0x4BEAEA: location_spec_to_sals(linespec_parser*, location_spec const*) [clone .lto_priv.0] (linespec.c:3079)
>    by 0xC70523: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) [clone .constprop.0] (linespec.c:3156)
>    by 0x28ED81: parse_breakpoint_sals(location_spec*, linespec_result*) (breakpoint.c:8899)
>    by 0x297394: create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:9250)
>    by 0xCCD77E: mi_cmd_break_insert_1(int, char const*, char const* const*, int) [clone .isra.0] (mi-cmd-break.c:368)
>    by 0x538772: mi_cmd_execute(mi_parse*) (mi-main.c:2148)
>    by 0x539CAC: UnknownInlinedFun (mi-main.c:1831)
>    by 0x539CAC: mi_execute_command(char const*, int) (mi-main.c:1955)
>    by 0x53A193: UnknownInlinedFun (mi-interp.c:219)
>    by 0x53A193: mi_execute_command_input_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (mi-interp.c:241)
>    by 0x3C75F6: gdb_readline_no_editing_callback(void*) (event-top.c:873)
>    by 0x79D73F: stdin_event_handler(int, void*) (ui.c:154)
>  Block was alloc'd at
>    at 0x4844F93: operator new(unsigned long) (vg_replace_malloc.c:487)
>    by 0x196B20: UnknownInlinedFun (new_allocator.h:151)
>    by 0x196B20: UnknownInlinedFun (alloc_traits.h:478)
>    by 0x196B20: UnknownInlinedFun (allocated_ptr.h:98)
>    by 0x196B20: UnknownInlinedFun (shared_ptr_base.h:967)
>    by 0x196B20: UnknownInlinedFun (shared_ptr_base.h:1713)
>    by 0x196B20: UnknownInlinedFun (shared_ptr.h:463)
>    by 0x196B20: UnknownInlinedFun (shared_ptr.h:1008)
>    by 0x196B20: gdb_exception::gdb_exception(return_reason, errors, char const*, __va_list_tag*) [clone .lto_priv.0] (common-exceptions.h:138)
>    by 0x196E87: UnknownInlinedFun (common-exceptions.h:276)
>    by 0x196E87: UnknownInlinedFun (common-exceptions.cc:203)
>    by 0x196E87: throw_verror(errors, char const*, __va_list_tag*) (common-exceptions.cc:211)
>    by 0xC2E59B: throw_error(errors, char const*, ...) (common-exceptions.cc:226)
>    by 0x4ADA97: UnknownInlinedFun (linespec.c:1644)
>    by 0x4ADA97: symtabs_from_filename(char const*, program_space*) (linespec.c:3738)
>    by 0x4BD52C: parse_linespec(linespec_parser*, char const*, symbol_name_match_type) (linespec.c:2558)
>    by 0x4BEAEA: location_spec_to_sals(linespec_parser*, location_spec const*) [clone .lto_priv.0] (linespec.c:3079)
>    by 0xC70523: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) [clone .constprop.0] (linespec.c:3156)
>    by 0x28ED81: parse_breakpoint_sals(location_spec*, linespec_result*) (breakpoint.c:8899)
>    by 0x297394: create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:9250)
>    by 0xCCD77E: mi_cmd_break_insert_1(int, char const*, char const* const*, int) [clone .isra.0] (mi-cmd-break.c:368)
>    by 0x538772: mi_cmd_execute(mi_parse*) (mi-main.c:2148)

symtabs_from_filename threw an exception here:
   by 0x4ADA97: symtabs_from_filename(char const*, program_space*)
(linespec.c:3738)
linespec.c:3738:
      source_file_not_found_error (filename);

It was caught 1 level up by parse_linespec at linespec.c:2561:
      catch (gdb_exception_error &ex)
        {
          file_exception = std::move (ex);
        }

And a bit further down re-thrown at linespec.c:2610:
      if (file_exception.reason < 0)
        throw_exception (std::move (file_exception));

This moved all gdb_exception contents from file_exception to the newly
thrown one, but it seems the destructor of file_exception still free'd
the original .message member, as seen here:
   by 0x16FAFE: parse_linespec(linespec_parser*, char const*,
symbol_name_match_type) [clone .cold] (linespec.c:2642)

The 2nd exception was caught by create_breakpoint, and when it tried
to print it at breakpoint.c:9264:
          exception_print (gdb_stderr, e);
It got the invalid read of the already free'd message at
common-exceptions.h:171:
    return message->c_str ();


I can reproduce this until the re-throw of file_exception, but once
throw_exception is called, file_exception.message is empty (since
it was moved), its destructor doesn't free anything, and exception_print
succeeds.

Why it's not the same for you I can't explain, maybe it makes more
sense for someone else.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
You seem to be compiling gdb with flto.

Does this problem also occur when using O0 instead?

What compiler and compiler version are you using?

On what architecture?

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

--- Comment #8 from Jarmo Tiitto <jarmo.tiitto at gmail dot com> ---
(In reply to Tom de Vries from comment #7)
> You seem to be compiling gdb with flto.
> 
> Does this problem also occur when using O0 instead?
I presume you mean the code I attached, which was built with -flto and -ggdb
flags, and not the gdb executable itself? 

> What compiler and compiler version are you using?
gcc (GCC) 14.2.1 20240910

> On what architecture?
x86-64, Linux.

I'm glad Hannes was able to catch something at least earlier.

If I build the reproducer code with "-g -std=gnu++20 -ggdb -fvar-tracking
-fvar-tracking-assignments -m64 -mfpmath=sse -ffast-math -Wall -Wshadow
-Wuninitialized -Wmaybe-uninitialized -Wmissing-field-initializers -O0
-D_DEBUG" flags, (Debug -O0, no LTO) I get:

(gdb)
&"No line 102 in file \"/usr/include/assert.h\".\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="n",addr="<PENDING>",pending="/usr/include/assert.h:102",times="0",original-location="/usr/include/assert.h:102"}
(gdb) 
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="n",addr="0x00000000000087ca",func="jh::CRHashtableAlgorithms<jh::Set<item,
item_key, hashbench::keyval_hash, hashbench::keyval_equal>
>::emplace<std::array<char, 8ul> const&, int>(std::array<char, 8ul> const&,
int&&)",file="/home/jarmo/gdbbug/include/crhashtable.hpp",fullname="/home/jarmo/gdbbug/include/crhashtable.hpp",line="307",thread-groups=["i1"],times="0",original-location="/home/jarmo/gdbbug/include/crhashtable.hpp:307"}
(gdb) 
^exit

That looks okay.
If I then re-build with "-O2 -g -DNDEBUG -std=gnu++20 -ggdb -fvar-tracking
-fvar-tracking-assignments -m64 -mfpmath=sse -ffast-math -Wall -Wshadow
-Wuninitialized -Wmaybe-uninitialized -Wmissing-field-initializers -O2
-fno-omit-frame-pointer" flags, (RelWithDebInfo, LTO disabled) I get:

(gdb) 
&"�\016\001a:W\n"        (<-- this should not get printed like this I think?)
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="n",addr="<PENDING>",pending="/usr/include/assert.h:102",times="0",original-location="/usr/include/assert.h:102"}
(gdb) 
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="n",addr="0x0000000000006c18",func="jh::Metatable::grow_and_clear()",file="/home/jarmo/gdbbug/include/crhashtable.hpp",fullname="/home/jarmo/gdbbug/include/crhashtable.hpp",line="307",thread-groups=["i1"],times="0",original-location="/home/jarmo/gdbbug/include/crhashtable.hpp:307"}
(gdb) 
^exit

And finally with "-O2 -g -DNDEBUG -std=gnu++20 -flto=auto -fno-fat-lto-objects
-ggdb -fvar-tracking -fvar-tracking-assignments -m64 -mfpmath=sse -ffast-math
-Wall -Wshadow -Wuninitialized -Wmaybe-uninitialized
-Wmissing-field-initializers -O2 -fno-omit-frame-pointer" flags,
(RelWithDebInfo, LTO enabled) I get:

(gdb) 
&"@\2215b\003Y\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="n",addr="<PENDING>",pending="/usr/include/assert.h:102",times="0",original-location="/usr/include/assert.h:102"}
(gdb) 
malloc(): smallbin double linked list corrupted
&"\n\n"
&"Fatal signal: "

So yeah, the problem is worsened with greater optimizations turned on.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jarmo Tiitto from comment #8)
> (In reply to Tom de Vries from comment #7)
> > You seem to be compiling gdb with flto.
> > 
> > Does this problem also occur when using O0 instead?

> I presume you mean the code I attached, which was built with -flto and -ggdb
> flags, and not the gdb executable itself? 

No, I mean the gdb executable itself.

The valgrind log you attached contains a symbol
_GLOBAL__sub_I__Z23symtab_to_symtab_objectP6symtab.lto_priv.0 , which looks to
me like it was created by an LTO optimization.

So, does the same problem occur when you build gdb without optimization, at
-O0?

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

--- Comment #10 from Jarmo Tiitto <jarmo.tiitto at gmail dot com> ---
Created attachment 15899
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15899&action=edit
valgrind log from GDB 15.2

(In reply to Tom de Vries from comment #9)
> (In reply to Jarmo Tiitto from comment #8)
> > (In reply to Tom de Vries from comment #7)
> > > You seem to be compiling gdb with flto.
> > >
> > > Does this problem also occur when using O0 instead?
>
> > I presume you mean the code I attached, which was built with -flto and -ggdb
> > flags, and not the gdb executable itself?
>
> No, I mean the gdb executable itself.
>
> The valgrind log you attached contains a symbol
> _GLOBAL__sub_I__Z23symtab_to_symtab_objectP6symtab.lto_priv.0 , which looks
> to me like it was created by an LTO optimization.
>
> So, does the same problem occur when you build gdb without optimization, at
> -O0?

I was unable remove all LTO syms from the produced valgrind logs.
(Arch linux by default builds distro pkgs with -O2 -flto=auto.)

I tried to disable most of the optimizations from the locally built pkgs and
then obtained valgrind logs for GDB 16.1 and GDB 15.2. The inferior executable
is the same from  reproducer.tar.gz

Now, neither locally built gdb 16.1 or 15.2 crashes to the reproducer but the
valgrind logs contain nearly same errors.

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[jarmo.tiitto at gmail dot com]

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

--- Comment #11 from Jarmo Tiitto <jarmo.tiitto at gmail dot com> ---
Created attachment 15900
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15900&action=edit
valgrind log from GDB 16.1

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

[Bug mi/32571] GDB Mi crashes when setting a disabled breakpoint

[ssbssa at sourceware dot org]

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

--- Comment #12 from Hannes Domani <ssbssa at sourceware dot org> ---
(In reply to Jarmo Tiitto from comment #10)
> Now, neither locally built gdb 16.1 or 15.2 crashes to the reproducer but
> the valgrind logs contain nearly same errors.

There are no invalid reads in the new logs.

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