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 8A1DC3852C5D for ; Mon, 21 Nov 2022 15:04:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A1DC3852C5D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3C03A1E0D3; Mon, 21 Nov 2022 10:04:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1669043053; bh=2Uf0tughLUnm4Kp0gE3hJV/bB9qA9RWheztVorg7Ktw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ilCFpghwQ1CCxVjcfKa1D8nxOBxvSAwBREU9xuqXZji/m2uHXKsktvQEWJ0heF6vv xDAUzRhpbkFg0RPg1pla+kSGDzWDjx1iUw9eVKGG4jJlFlBp+xlu8PAZJKtJZtlMbX 5QVRqOM4yAXpRXf/RAGeXjq4iCObUfwHLjjA5k0Y= Message-ID: <837bc907-5488-aa04-b656-b4ab9319519e@simark.ca> Date: Mon, 21 Nov 2022 10:04:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [RFA] When getting the locno of a bpstat, handle the case of bp with null locations. Content-Language: en-US To: Philippe Waroquiers , gdb-patches@sourceware.org References: <20221120173024.3647464-1-philippe.waroquiers@skynet.be> From: Simon Marchi In-Reply-To: <20221120173024.3647464-1-philippe.waroquiers@skynet.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/20/22 12:30, Philippe Waroquiers via Gdb-patches wrote: > The test py-objfile.exp unloads the current file while debugging the process. > This results in bpstat bs->b->loc to become nullptr. > Handle this case in breakpoint.c:bpstat_locno. > > Note: GDB crashes on this problem with an internal error, > but the end of gdb summary shows: > ... > === gdb Summary === > > # of expected passes 36 > > The output also does not contain a 'FAIL:'. > After the dix, the nr of expeted passes increased. dix->fix expeted -> expected > > In the gdb.log output, one can see: > ... > Fatal signal: Segmentation fault > ----- Backtrace ----- > 0x55698905c5b9 gdb_internal_backtrace_1 > ../../binutils-gdb/gdb/bt-utils.c:122 > 0x55698905c5b9 _Z22gdb_internal_backtracev > ... > > ERROR: Couldn't send python print(objfile.filename) to GDB. > ERROR: : spawn id exp9 not open > while executing > "expect { > -i exp9 -timeout 10 > -re ".*A problem internal to GDB has been detected" { > fail "$message (GDB internal error)" > gdb_internal_error..." > ("uplevel" body line 1) > invoked from within > .... > > Wondering if it might be possible to improve gdb_test to have > gdb_test "python print(objfile.filename)" "None" \ > "objfile.filename after objfile is unloaded" > reporting a failed result instead of just producing the internal error. I think an UNRESOLVED would be appropriate here. Normally, it should do that automatically. The perror here: https://gitlab.com/gnutools/binutils-gdb/-/blob/84f9fbe90e5429adb9dee68f04f44c92fa9e2345/gdb/testsuite/lib/gdb.exp#L1183 ... should make it so the next pass/fail becomes an UNRESOLVED. However, we don't even reach a pass / fail, as the expect call throws the error you pasted above, about the spawn id not being open. This mechanism works if GDB hasn't crashed yet when entering gdb_test_multiple, and it's the command gdb_test_multiple sends that crashes GDB. But here, what crashed GDB is the previous gdb_unload call, which uses bare expect, leaving no trace of the crash (in terms of test result). I propose the following changes to handle this situation better: - make gdb_unload use gdb_test_multiple, to make it record a test result and handle the different failure modes - instead of calling perror, manually call unresolved as soone as send_gdb returns an error, and return -1 immediately, to handle more gracefully the case where GDB is already crashed on entry But this is orthogonal with your patch, I will send a separate series. Your patch LGTM: Approved-By: Simon Marchi Simon