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 34465385802F for ; Mon, 6 Nov 2023 17:05:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34465385802F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 34465385802F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699290330; cv=none; b=Qh8Tn3DkF0551RgDMPzL1z8315hNhMbp7xFyri97Kqqg+g9tNeHGMAqwM5efsCrJXyDd6JMCK0OYQNKsLlvAWDgHYwUWjfnYl0QWS1tjs0+70N+LGKCBYJaktQVA+P+CZkwkpMsMXTVV0rOGCt4+W/R+nv+cK/Yqm9OYlOsh4pE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699290330; c=relaxed/simple; bh=htltDSpA1LAOADljEBTT5UB4JWgfcGSWKRhuMn9iwBI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ge6FJ2Lvvr+L43k/5jAX20FlMpz17C26B1yZKt+fHuSZXIuj7gW2kpqkkAfEzNywrFrJ4iscC9gj//vko/YyUl7zBR8tqu+BUKq0Pgs16OYFJOvjqQ9AdJgIRuXVu9evjMaKC87vpdd9JSjUFVzJP/TYt7B/NpVEsMSDH/TTa8o= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1699290328; bh=htltDSpA1LAOADljEBTT5UB4JWgfcGSWKRhuMn9iwBI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=RzbMZ4ygpw5kGj8IeAeeFGBTi0pGEuGFtii8EkyzA45fTcZtUuiJ3EEwqVlYJW+tr kUBV0akJgO0kJzQ6vohoCPJaM/xHg407tp9v2wFXa2oZq3M/99MCLzfaIawgRhqVYY 6VkJ0sssj2IYMIqtD9ADKBEwgt5W+drV/hYe0HFk= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id CF6911E00F; Mon, 6 Nov 2023 12:05:28 -0500 (EST) Message-ID: <3040273d-76d9-43a3-a9a6-5b7225276cc6@simark.ca> Date: Mon, 6 Nov 2023 12:05:28 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] [gdb] Fix segfault in for_each_block, part 1 Content-Language: fr To: Tom de Vries , gdb-patches@sourceware.org References: <20231104155757.16649-1-tdevries@suse.de> <20231104155757.16649-2-tdevries@suse.de> From: Simon Marchi In-Reply-To: <20231104155757.16649-2-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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/4/23 11:57, Tom de Vries wrote: > When running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise > on s390x), I run into: > ... > (gdb) PASS: gdb.base/vfork-follow-parent.exp: \ > exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \ > resolution_method=schedule-multiple: print unblock_parent = 1 > continue^M > Continuing.^M > Reading symbols from vfork-follow-parent-exit...^M > ^M > ^M > Fatal signal: Segmentation fault^M > ----- Backtrace -----^M > 0x1027d3e7 gdb_internal_backtrace_1^M > src/gdb/bt-utils.c:122^M > 0x1027d54f _Z22gdb_internal_backtracev^M > src/gdb/bt-utils.c:168^M > 0x1057643f handle_fatal_signal^M > src/gdb/event-top.c:889^M > 0x10576677 handle_sigsegv^M > src/gdb/event-top.c:962^M > 0x3fffa7610477 ???^M > 0x103f2144 for_each_block^M > src/gdb/dcache.c:199^M > 0x103f235b _Z17dcache_invalidateP13dcache_struct^M > src/gdb/dcache.c:251^M > 0x10bde8c7 _Z24target_dcache_invalidatev^M > src/gdb/target-dcache.c:50^M > ... > or similar. > > The root cause for the segmentation fault is that linux_is_uclinux gives an > incorrect result: it should always return false, given that we're running on a > regular linux system, but instead it returns first true, then false. > > In more detail, the segmentation fault happens as follows: > - a program space with an address space is created > - a second program space is about to be created. maybe_new_address_space > is called, and because linux_is_uclinux returns true, maybe_new_address_space > returns false, and no new address space is created > - a second program space with the same address space is created > - a program space is deleted. Because linux_is_uclinux now returns false, > gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns > false, and the address space is deleted > - when gdb uses the address space of the remaining program space, we run into > the segfault, because the address space is deleted. > > Hardcoding linux_is_uclinux to false makes the test-case pass. > > We leave addressing the root cause for the following commit in this series. > > For now, prevent the segmentation fault by making the address space a refcounted > object. > > This was already suggested here [1]: > ... > A better solution might be to have the address spaces be reference counted > ... That reminded me of a patch I started to work on a while ago to remove program_space::aspace, which I have to get back to. The rationale is that there might be a 1:N relation ship between one program space and many address spaces (see diagram in progspace.h), so having this one pointer does not represent well the relationship. An inferior is always bound to a single address space, so my patch changes the code to use inferior::aspace instead. I think that even with my patch, we would still have the problem of knowing when to delete an address space. When you have many inferiors sharing an address space, and you delete an inferior, how do you know if you should delete the address space? Perhaps we can implement a method like program_space::empty, but for address_space. However, I still think that using refcounting for address spaces (and perhaps for program spaces too?) is a good solution. It would spare us of having to deal with the logic of knowing when address space is no longer used. Refcounting isn't always the right solution, but I don't see any downsides in this case. Implementation question: is there any reason you didn't choose std::shared_ptr? For objects that are new'ed / delete'd, that seems like a good choice. Simon