From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 36D0D3858D3C for ; Fri, 18 Mar 2022 15:57:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 36D0D3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BB6551EA69; Fri, 18 Mar 2022 11:57:26 -0400 (EDT) Message-ID: Date: Fri, 18 Mar 2022 11:57:26 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: GDB crashes when using GDB/MI and python pretty printers in some cases Content-Language: tl To: Jan Vrany , GDB mailing list References: From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3639.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2022 15:57:28 -0000 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 > 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 > 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