From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8GPONHXrO2GHQAAAWB0awg (envelope-from ) for ; Fri, 10 Sep 2021 19:34:13 -0400 Received: by simark.ca (Postfix, from userid 112) id C46101EE24; Fri, 10 Sep 2021 19:34:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 62EF71EE1F for ; Fri, 10 Sep 2021 19:34:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A8CCC3858437 for ; Fri, 10 Sep 2021 23:34:11 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 08EB3385840C for ; Fri, 10 Sep 2021 23:34:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08EB3385840C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id C2A80841E6; Fri, 10 Sep 2021 23:33:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H5sdd4szrz3ncr; Fri, 10 Sep 2021 23:33:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 476247385; Fri, 10 Sep 2021 23:33:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH 6/6] gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child" To: Simon Marchi , gdb-patches@sourceware.org References: <20210910205402.3853607-1-simon.marchi@efficios.com> <20210910205402.3853607-6-simon.marchi@efficios.com> From: John Baldwin Message-ID: <021ba846-e43e-e6ef-c827-7e2b8ff8f5e9@FreeBSD.org> Date: Fri, 10 Sep 2021 16:33:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210910205402.3853607-6-simon.marchi@efficios.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 9/10/21 1:54 PM, Simon Marchi via Gdb-patches wrote: > We found that when handling forks, two inferiors can unexpectedly share > their program space and address space. To reproduce: > > 1. Using a test program that forks... > 2. "set follow-fork-mode child" > 3. "set detach-on-fork on" (the default) > 4. run to a breakpoint somewhere after the fork > > Step 4 should have created a new inferior: > > (gdb) info inferiors > Num Description Connection Executable > 1 /home/smarchi/build/wt/amd/gdb/fork > * 2 process 251425 1 (native) /home/smarchi/build/wt/amd/gdb/fork > > By inspecting the state of GDB, we can see that the two inferiors now > share one program space and one address space: > > Inferior 1: > > (top-gdb) p inferior_list.m_front.num > $2 = 1 > (top-gdb) p inferior_list.m_front.aspace > $3 = (struct address_space *) 0x5595e2520400 > (top-gdb) p inferior_list.m_front.pspace > $4 = (struct program_space *) 0x5595e2520440 > > Inferior 2: > > (top-gdb) p inferior_list.m_front.next.num > $5 = 2 > (top-gdb) p inferior_list.m_front.next.aspace > $6 = (struct address_space *) 0x5595e2520400 > (top-gdb) p inferior_list.m_front.next.pspace > $7 = (struct program_space *) 0x5595e2520440 > > You can then run inferior 1 again and the two inferiors will still > erroneously share their spaces, but already at this point this is wrong. > > The cause of the bad {a,p}space sharing is in follow_fork_inferior. > When following the child and detaching from the parent, we just re-use > the parent's spaces, rather than cloning them. When we switch back to > inferior 1 and run again, we find ourselves with two unrelated inferiors > sharing spaces. > > Fix that by creating new spaces for the parent after having moved them > to the child. My initial implementation created new spaces for the > child instead. Doing this breaks doing "next" over fork(). When "next" > start, we record the symtab of the starting location. When the program > stops, we compare that symtab with the symtab the program has stopped > at. If the symtab or the line number has changed, we conclude the > "next" is done. If we create a new program space for the child and copy > the parent's program space to it with clone_program_space, it creates > new symtabs for the child as well. When the child stop, but still on > the fork() line, GDB thinks the "next" is done because the symtab > pointers no longer match. In reality they are two symtab instances that > represent the same file. But moving the spaces to the child and > creating new spaces for the parent, we avoid this problem. > > Note that the problem described above happens today with "detach-on-fork > off" and "follow-fork-mode child", because we create new spaces for the > child. This will have to be addressed later. > > Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is > expected to have a location in each inferiors. Without the fix, when > the two inferiors erroneously share a program space, GDB reports a > single location. So I wonder about the case where follow-fork-mode is parent and detach-on-fork is off? In that case, should the existing aspace/pspace stay with the parent and the child get clones? That is, using the follow-fork-mode setting to determine which inferior gets the existing aspace/pspace and assigning the cloned copies to the !follow-fork-mode inferior? -- John Baldwin