Re: GDB crashes when using GDB/MI and python pretty printers in some cases

[Simon Marchi <simark@simark.ca>]

On 2022-03-17 09:29, Jan Vrany via Gdb wrote:
> Hi Simon, others,
> 
> TL;DR: 
> 
> I'm experiencing GDB crashes with recent GDB which seem to be
> caused by commit 5f8ab46. Why is that I do not know (yet). Some 
> details below.
> 
> Full story:
> 
> After updating my every-day-use GDB to commit 
> 
> commit c9178f285acf19e066be8367185d52837161b0a2 (HEAD -> master, origin/master)
> Author: Alan Modra <amodra@gmail.com>
> Date:   Thu Mar 17 20:05:39 2022 +1030
> 
> I'm experiencing GDB to crash on assertion failure in value_copy (value.c:1731).
> This is triggered when I single-step through code while having (my, custom) GDB/MI
> frontent displaying local variables with python pretty printers enabled. 
> 
> For example: doing this in frontend triggers the assertion failure:
> 
>     file gdb/testsuite/outputs/gdb.python/py-prettyprint/py-prettyprint-cxx
>     source gdb/testsuite/outputs/gdb.python/py-prettyprint/py-prettyprint.py
>     b add_item(container*, int)
>     r
>     dis 1
>     fin
>     n
>     n (few more times until it crashes)
> 
> This is the backtrace when it crashes: 
> 
>     /home/jv/Proj...atches/gdb/gdb [stopped]
>       Thread  1 [stopped] "gdb"
>          0 0x0000556077ADABD0 internal_error (errors.cc:51)
>          1 0x00005560776148A7 value_copy (value.c:1731)
>          2 0x0000556077360028 gdbpy_get_varobj_pretty_printer (py-prettyprint.c:655)
>          3 0x0000556077620E60 install_default_visualizer (varobj.c:1056)
>          4 0x00005560776210E9 install_new_value_visualizer (varobj.c:1127)
>          5 0x00005560776218B2 install_new_value (varobj.c:1339)
>          6 0x000055607761F6FB varobj_create (varobj.c:378)
>          7 0x0000556077245C05 mi_cmd_var_create (mi-cmd-var.c:132)
>          8 0x0000556077249F2B mi_command_mi::invoke (mi-cmds.c:58)
>          9 0x0000556077264F15 mi_cmd_execute (mi-main.c:2091)
>         10 0x000055607726450C captured_mi_execute_command (mi-main.c:1823)
>         11 0x000055607726498A mi_execute_command (mi-main.c:1947)
>         12 0x000055607724D21B mi_execute_command_wrapper (mi-interp.c:285)
>         13 0x000055607724D2A4 mi_execute_command_input_handler (mi-interp.c:314)
>         14 0x00005560770D7149 gdb_readline_no_editing_callback (event-top.c:878)
>         15 0x00005560770D6948 stdin_event_handler (event-top.c:524)
>         16 0x0000556077ADB57E gdb_wait_for_event (event-loop.cc:700)
>         17 0x0000556077ADB7FB gdb_wait_for_event (event-loop.cc:596)
>         18 0x0000556077ADB7FB gdb_do_one_event (event-loop.cc:237)
>         19 0x000055607721BA1B start_event_loop (main.c:421)
>         20 0x000055607721BB3F captured_command_loop (main.c:481)
>         21 0x000055607721D535 captured_main (main.c:1351)
>         22 0x000055607721D59B gdb_main (main.c:1366)
>         23 0x0000556076DA7E93 main (gdb.c:32)
>       Thread  2 [stopped] "gdb worker"
>       Thread  3 [stopped] "gdb worker"
>       Thread  4 [stopped] "gdb worker"
>       Thread  5 [stopped] "gdb worker"
> 
> 
> Unfortunately, so far I was unable to reproduce this outside my frontend. I tried
> to simulate what the frontend does (see attached file), but running GDB like 
> 
> 
>    gdb -i mi < crash-in-value_copy-reproducer.txt 
> 
> 
> does not trigger it (arguably, the frontend issues silly / unnecessary MI commands, but still
> it should not crash GDB - I would think :-). 
> 
> If I revert commit
> 
> 
> commit 5f8ab46bc6918efb678deb5956c033e466afe301
> Author: Simon Marchi <simon.marchi@polymtl.ca>
> Date:   Mon Jan 31 15:57:58 2022 -0500
> 
>     gdb: constify parameter of value_copy
> 
> Everything seems to work just fine for me. I'm not at all familiar with this
> part of the GDB code so I do not know whether this change is the real culprit 
> or not, let alone to explain why.
> 
> I'll try to investigate further when I find more time, but in case someone brave
> enough to read through this post has an idea, I'll appreciate it! 
> 
> Thanks, Jan

Can you file a bug?  Even if you don't have a simple reproducer yet, that's fine, include
the same info you gave above.

Simon