From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C6D613858C5E for ; Thu, 22 Jun 2023 13:17:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6D613858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687439859; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mKzH9MLKVP5xgcDn1f82J9gu64ht1G+TBO+TnqY596I=; b=JENf3nqHRxNPPZ0Hdqk5SdLEEQ66WuQykVgTeRFP1L2psFbf407YW+3VkczBfM7z2UEvMi 63ivtrQ9EitvEhLRuddo0GWFrwmcYgCzZmO4y/QoY7SCvq1asEN2V/rplUCDURDo4Bl4Te 5nkbS5X4ltBEUOfcp7BWZ3XT2YzOwfA= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-107-doRrUe6oPIGoN586Ez4_cg-1; Thu, 22 Jun 2023 09:17:38 -0400 X-MC-Unique: doRrUe6oPIGoN586Ez4_cg-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3128319d532so1470507f8f.2 for ; Thu, 22 Jun 2023 06:17:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687439856; x=1690031856; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mKzH9MLKVP5xgcDn1f82J9gu64ht1G+TBO+TnqY596I=; b=hA+tpqXOfD6Cd9PY+pVMjR8Cf28lfswBqiha2JXzsKRJMuLhUP3MyLEJGZQQZtuMo2 Y/M+xa5izU7/lJZIS1ssFb7HTlaDWBtTtJnfQNDjbD0YbUKHm/+LXt8CwHkqqp7nL/3q 85PIg1PYKz0xdE9cVETRbp4tvC67idubGsW35F7uLzOk89VAeELZmDdZYrc+9JBOCeMS qLroyOHqZOOUjTZLcqyr2amIMYpEB2HVbQ/hN8bnFrp6fupPdV1flmxQnH+ViyUjSMHm mdJ9c+fqrFM2c9ki6GnoSwxZoZpi4sYpt/mGNDYbJD3tunigro67IIu2x9gmXWqQRjkZ KckQ== X-Gm-Message-State: AC+VfDyXoAHD9TU1CQygPp8eL6rvwlXLjgxz2C4U7LqgZnG/h6TVOmx8 05BzTL7QNKT+cM4b0yR6Vbui2L0fxuSNhByUpzIn2i91dQzo/YlS4UxklaOLo9OcfK/obFm178y DR7KCw92BOVfTL3eCiLTElorFq06xOAa9OKmzxRK2m5i3ilVkwniYJBeKteOTwlz4KQpD6AzJW0 IhQqGFHA== X-Received: by 2002:adf:ef8d:0:b0:30d:f75c:4a68 with SMTP id d13-20020adfef8d000000b0030df75c4a68mr14957930wro.34.1687439856490; Thu, 22 Jun 2023 06:17:36 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7oRq2nz0bhTFRN4bIOOj5V0/DErcXKLYO1APs3a+8BWfx0mnqFpo/4wH/tl0QwVj6OMPU5Ig== X-Received: by 2002:adf:ef8d:0:b0:30d:f75c:4a68 with SMTP id d13-20020adfef8d000000b0030df75c4a68mr14957910wro.34.1687439855914; Thu, 22 Jun 2023 06:17:35 -0700 (PDT) Received: from localhost (2.72.115.87.dyn.plus.net. [87.115.72.2]) by smtp.gmail.com with ESMTPSA id b13-20020a5d4d8d000000b003048477729asm7056736wru.81.2023.06.22.06.17.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jun 2023 06:17:35 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 2/8] gdb: don't restart vfork parent while waiting for child to finish Date: Thu, 22 Jun 2023 14:17:22 +0100 Message-Id: <4e555fe2fbcd591b5a50e5f5f21ac30f48e7fab1.1687438786.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: While working on a later patch, which changes gdb.base/foll-vfork.exp, I noticed that sometimes I would hit this assert: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. I eventually tracked it down to a combination of schedule-multiple mode being on, target-non-stop being off, follow-fork-mode being set to child, and some bad timing. The failing case is pretty simple, a single threaded application performs a vfork, the child process then execs some other application while the parent process (once the vfork child has completed its exec) just exits. As best I understand things, here's what happens when things go wrong: 1. The parent process performs a vfork, GDB sees the VFORKED event and creates an inferior and thread for the vfork child, 2. GDB resumes the vfork child process. As schedule-multiple is on and target-non-stop is off, this is translated into a request to start all processes (see user_visible_resume_ptid), 3. In the linux-nat layer we spot that one of the threads we are about to start is a vfork parent, and so don't start that thread (see resume_lwp), the vfork child thread is resumed, 4. GDB waits for the next event, eventually entering linux_nat_target::wait, which in turn calls linux_nat_wait_1, 5. In linux_nat_wait_1 we eventually call resume_stopped_resumed_lwps, this should restart threads that have stopped but don't actually have anything interesting to report. 6. Unfortunately, resume_stopped_resumed_lwps doesn't check for vfork parents like resume_lwp does, so at this point the vfork parent is resumed. This feels like the start of the bug, and this is where I'm proposing to fix things, but, resuming the vfork parent isn't the worst thing in the world because.... 7. As the vfork child is still alive the kernel holds the vfork parent stopped, 8. Eventually the child performs its exec and GDB is sent and EXECD event. However, because the parent is resumed, as soon as the child performs its exec the vfork parent also sends a VFORK_DONE event to GDB, 9. Depending on timing both of these events might seem to arrive in GDB at the same time. Normally GDB expects to see the EXECD or EXITED/SIGNALED event from the vfork child before getting the VFORK_DONE in the parent. We know this because it is as a result of the EXECD/EXITED/SIGNALED that GDB detaches from the parent (see handle_vfork_child_exec_or_exit for details). Further the comment in target/waitstatus.h on TARGET_WAITKIND_VFORK_DONE indicates that when we remain attached to the child (not the parent) we should not expect to see a VFORK_DONE, 10. If both events arrive at the same time then GDB will randomly choose one event to handle first, in some cases this will be the VFORK_DONE. As described above, upon seeing a VFORK_DONE GDB expects that (a) the vfork child has finished, however, in this case this is not completely true, the child has finished, but GDB has not processed the event associated with the completion yet, and (b) upon seeing a VFORK_DONE GDB assumes we are remaining attached to the parent, and so resumes the parent process, 11. GDB now handles the EXECD event. In our case we are detaching from the parent, so GDB calls target_detach (see handle_vfork_child_exec_or_exit), 12. While this has been going on the vfork parent is executing, and might even exit, 13. In linux_nat_target::detach the first thing we do is stop all threads in the process we're detaching from, the result of the stop request will be cached on the lwp_info object, 14. In our case the vfork parent has exited though, so when GDB waits for the thread, instead of a stop due to signal, we instead get a thread exited status, 15. Later in the detach process we try to resume the threads just prior to making the ptrace call to actually detach (see detach_one_lwp), as part of the process to resume a thread we try to touch some registers within the thread, and before doing this GDB asserts that the thread is stopped, 16. An exited thread is not classified as stopped, and so the assert triggers! So there's two bugs I see here. The first, and most critical one here is in step #6. I think that resume_stopped_resumed_lwps should not resume a vfork parent, just like resume_lwp doesn't resume a vfork parent. With this change in place the vfork parent will remain stopped in step instead GDB will only see the EXECD/EXITED/SIGNALLED event. The problems in #9 and #10 are therefore skipped and we arrive at #11, handling the EXECD event. As the parent is still stopped #12 doesn't apply, and in #13 when we try to stop the process we will see that it is already stopped, there's no risk of the vfork parent exiting before we get to this point. And finally, in #15 we are safe to poke the process registers because it will not have exited by this point. However, I did mention two bugs. The second bug I've not yet managed to actually trigger, but I'm convinced it must exist: if we forget vforks for a moment, in step #13 above, when linux_nat_target::detach is called, we first try to stop all threads in the process GDB is detaching from. If we imagine a multi-threaded inferior with many threads, and GDB running in non-stop mode, then, if the user tries to detach there is a chance that thread could exit just as linux_nat_target::detach is entered, in which case we should be able to trigger the same assert. But, like I said, I've not (yet) managed to trigger this second bug, and even if I could, the fix would not belong in this commit, so I'm pointing this out just for completeness. There's no test included in this commit. In a couple of commits time I will expand gdb.base/foll-vfork.exp which is when this bug would be exposed. Unfortunately there are at least two other bugs (separate from the ones discussed above) that need fixing first, these will be fixed in the next commits before the gdb.base/foll-vfork.exp test is expanded. If you do want to reproduce this failure then you will for certainly need to run the gdb.base/foll-vfork.exp test in a loop as the failures are all very timing sensitive. I've found that running multiple copies in parallel makes the failure more likely to appear, I usually run ~6 copies in parallel and expect to see a failure after within 10mins. --- gdb/linux-nat.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c index 383ef58fa23..7e121b7ab41 100644 --- a/gdb/linux-nat.c +++ b/gdb/linux-nat.c @@ -3346,7 +3346,14 @@ linux_nat_wait_1 (ptid_t ptid, struct target_waitstatus *ourstatus, static int resume_stopped_resumed_lwps (struct lwp_info *lp, const ptid_t wait_ptid) { - if (!lp->stopped) + struct inferior *inf = find_inferior_ptid (linux_target, lp->ptid); + + if (inf->vfork_child != nullptr) + { + linux_nat_debug_printf ("NOT resuming LWP %s (vfork parent)", + lp->ptid.to_string ().c_str ()); + } + else if (!lp->stopped) { linux_nat_debug_printf ("NOT resuming LWP %s, not stopped", lp->ptid.to_string ().c_str ()); -- 2.25.4