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.133.124]) by sourceware.org (Postfix) with ESMTPS id 63A6B3858D32 for ; Mon, 10 Jul 2023 11:10:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63A6B3858D32 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=1688987408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M0AT/ujfGrrn58qJw289Wc046LXGlQqUQFdHni1Vs1Y=; b=dcwaXGTFvA5hPSyzTNP7g+r6UitWzOtRDcH1QEI3SHhGI78Njmss7tFoJe7COTlQTEQoDt i/mnBVCgygcPHWYn56U715jXeXfNIdV34HVeWr8NQMVFL4MM64cl0L61qKJkFhDChR7zhB QTRc8fRo8YgHlUjcn+lSydyVdSHF/vY= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-470-squRyjj2PZ6YADJArNfM7Q-1; Mon, 10 Jul 2023 07:10:07 -0400 X-MC-Unique: squRyjj2PZ6YADJArNfM7Q-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-3fa9a282fffso25035205e9.1 for ; Mon, 10 Jul 2023 04:10:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688987406; x=1691579406; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M0AT/ujfGrrn58qJw289Wc046LXGlQqUQFdHni1Vs1Y=; b=ZWTC2Sx8/2f88indnG1I70+Rq4AwWT4R5vziBFkm4yVTbYULj4/S3uEQNvLWSxwQMV tx4ZURtno1j+eAEg/hPGAgt6vJMAw40/P6kBO+qR8AFT+/i7Snf/0eqY3G80CB+1uQG3 TGT4TvmXd5CjZ3Y9xL8dSWjr4W4wmqPMP/ng26TJByL1sz8HPHgoBqkmbYjEZL8OLD0M nVkpcvc8N2hwxyJ1TM1/bu52qF/h82d9HPHJRZ6AK1o6ehdWPAZyRUb10uVbjw/Lx/WA oSr70gVpAgJfW2cdtfhLUH55n4tiRVCGZAYIa98ADGnWxeidY5OFZTIF7z6XBVKhTeeK +PuA== X-Gm-Message-State: ABy/qLYaTqyYB6A9SUDCywchNghn12rpAaB8xKKpQSi8pxnEOzcFjCfk fNBqKqO3MuU5Vbz8iVWGNRJMukHgu8Ul6ju+KqaYhxVRiwESdWaxzXMXx405tS8XEmsEa3QJxr+ PoWC9DD+0153wxq6Dl4XsXqSZjJ7zOhqv5lKSf88vNIZeUAKqxdRiLnOeuR6zpLXnqIMQEm824b edU0ydTA== X-Received: by 2002:a1c:7206:0:b0:3fb:8284:35b0 with SMTP id n6-20020a1c7206000000b003fb828435b0mr9918837wmc.30.1688987405203; Mon, 10 Jul 2023 04:10:05 -0700 (PDT) X-Google-Smtp-Source: APBJJlESEXVDHOz0Ni+APVFCw93i0XKkpvAaoXAQW7RvmAZz+2NLv7CucGyjhY3/IZbZXvFJwEo2NA== X-Received: by 2002:a1c:7206:0:b0:3fb:8284:35b0 with SMTP id n6-20020a1c7206000000b003fb828435b0mr9918802wmc.30.1688987404626; Mon, 10 Jul 2023 04:10:04 -0700 (PDT) Received: from localhost (2.72.115.87.dyn.plus.net. [87.115.72.2]) by smtp.gmail.com with ESMTPSA id u10-20020a7bcb0a000000b003fbb346279dsm10062221wmj.38.2023.07.10.04.10.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jul 2023 04:10:04 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] gdb/testsuite: add test for core file with a 0 pid In-Reply-To: <6cb39b064b3e1c9ed57964b29fd980f3a6d30a25.1685956034.git.aburgess@redhat.com> References: <6cb39b064b3e1c9ed57964b29fd980f3a6d30a25.1685956034.git.aburgess@redhat.com> Date: Mon, 10 Jul 2023 12:10:03 +0100 Message-ID: <87bkgkja44.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,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: Andrew Burgess writes: > This patch contains a test for this commit: > > commit c820c52a914cc9d7c63cb41ad396f4ddffff2196 > Date: Fri Aug 6 19:45:58 2010 +0000 > > * thread.c (add_thread_silent): Use null_ptid instead of > minus_one_ptid while getting rid of stale inferior_ptid. > > This is another test that has been carried in the Fedora GDB tree for > some time, and I thought that it would be worth merging to master. I > don't believe there is any test like this currently in the testsuite. > > The original issue was reported in this thread: > > https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/ > > The problem was that when GDB was used to open a vmcore (core file) > image generated by the Linux kernel GDB would (sometimes) crash with > an assertion failure: > > thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed. > > To understand what's going on we need some background; a vmcore file > represents each processor core in the same way that a standard > application core file represents threads. Thus, we might say, a > vmcore file represents cores as threads. > > When writing a vmcore file, the kernel will store the pid of the > process currently running on that core as the thread's lwpid. > > However, if a core is idle, with no process currently running on it, > then the lwpid for that thread is stored as 0 in the vmcore file. If > multiple cores are idle then multiple threads will have a lwpid of 0. > > Back in 2010, the original issue reported tried to change the kernel's > behaviour in this thread: > > https://lkml.org/lkml/2010/8/3/75 > > This change was rejected by the kernel team, the current > behaviour (lwpid of 0) was considered correct. I've checked the > source of a recent kernel. The code mentioned in the lkml.org posting > has moved, it's now in the function crash_save_cpu in the file > kernel/kexec_core.c, but the general behaviour is unchanged, an idle > core will have an lwpid of 0, so I think GDB still needs to be able to > handle this case. > > When GDB loads a vmcore file (which is handled just like any other > core file) the sections are processed in core_open to generate the > threads for the core file. The processing is done by calling > add_to_thread_list, a function which looks for sections named .reg/NN > where NN is the lwpid of the thread, GDB then builds a ptid_t for the > new thread and calls add_thread. > > Remember, in our case the lwpid is 0. Now for the first thread this > is fine, if a little weird, 0 isn't usually a valid lwpid, but that's > OK, GDB creates a thread with lwpid of 0 and carries on. > > When we find the next thread (core) with lwpid of 0, we attempt to > create another thread with an lwpid of 0. This of course clashes with > the previously created thread, they have the same ptid_t, so GDB tries > to delete the first thread. > > And it was within this thread delete code that we triggered a bug > which would then cause GDB to assert -- when deleting we tried to > switch to a thread with minus_one_ptid, this resulted in a call to > find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the > find_inferior_pid call fails and returns NULL, which then triggered an > assert in switch_to_thread. > > The actual details of the why the assert triggered are really not > important. What's important (I think) is that a vmcore file might > have this interesting lwpid of 0 characteristic, which isn't something > we see in "normal" application core files, and it is this that I think > we should be testing. > > Now, you might be thinking: isn't deleting the first thread the wrong > thing to do? If the vmcore file has two threads that represent two > cores, and both have an lwpid of 0 (indicating both cores are idle), > then surely GDB should still represent this as two threads? You're > not wrong. This was mentioned by Pedro in the original GDB mailing > list thread here: > > https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/ > > This is indeed a problem, and this problem is still present in GDB > today. I plan to try and address this in a later commit, however, > this first commit is about getting a test in place to confirm that GDB > at a minimum doesn't crash when loading such a vmcore file. > > And so, finally, what's in this commit? > > This commit contains a new test. The test doesn't actually contain a > vmcore file. Instead I've created a standard application core file > that contains two threads, and then manually edited the core file to > set the lwpid of each thread to 0. > > To further reduce the size of the core file (as it will be stored in > git), I've zeroed all of the LOAD-able segments in the core file. > This test really doesn't care about that part of the core file, we > only really care about loading the register's, this is enough to > confirm that the GDB doesn't crash. > > Obviously as the core file is pre-generated, this test is architecture > specific. There are already a few tests in gdb.arch/ that include > pre-generate core files. Just as those existing tests do, I've > compressed the core file with bzip2, which reduces it to just 750 > bytes. I have structured the test so that if/when this patch is > merged I can add some additional core files for other architectures, > however, these are not included in this commit. > > The test simply expands the core file, and then loads it into GDB. > One interesting thing to note is that GDB reports the core file > loading like this: > > (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core > [New process 1] > [New process 1] > Failed to read a valid object file image from memory. > Core was generated by `./segv-mt'. > Program terminated with signal SIGSEGV, Segmentation fault. > The current thread has terminated > (gdb) > > There's two interesting things here: first, the repeated "New process > 1" message. This is caused because linux_core_pid_to_str reports > anything with an lwpid of 0 as a process, rather than an LWP. And > second, the "The current thread has terminated" message. This is > because the first thread in the core file is the current thread, but > when GDB loads the second thread (which also has lwpid 0) this causes > the first thread to be deleted, as a result GDB thinks that the > current (first) thread has terminated. > > As I said previously, both of these problems are a result of the lwpid > 0 aliasing, which is not being fixed in this commit -- this commit is > just confirming that GDB doesn't crash when loading this core file. > --- > gdb/testsuite/gdb.arch/core-file-pid0.exp | 63 ++++++++++++++++++ > .../gdb.arch/core-file-pid0.x86-64.core.bz2 | Bin 0 -> 750 bytes > 2 files changed, 63 insertions(+) > create mode 100644 gdb/testsuite/gdb.arch/core-file-pid0.exp > create mode 100644 gdb/testsuite/gdb.arch/core-file-pid0.x86-64.core.bz2 > > diff --git a/gdb/testsuite/gdb.arch/core-file-pid0.exp b/gdb/testsuite/gdb.arch/core-file-pid0.exp > new file mode 100644 > index 00000000000..b960dfe095b > --- /dev/null > +++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp > @@ -0,0 +1,63 @@ > +# This testcase is part of GDB, the GNU debugger. > +# > +# Copyright 2023 Free Software Foundation, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 2 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > + > +# Some kernel core files have PID 0 (for the idle task), check that > +# GDB can handle such a core file. > + > +standard_testfile > + > +# Set CF_NAME, the name of the compressed core file within the source > +# tree, and CF_SIZE, the size (in bytes) of the uncompressed core > +# file. > +if {[istarget "x86_64-*-linux*"]} { > + set cf_name ${testfile}.x86-64.core.bz2 > + set cf_size 8757248 > +} else { > + unsupported "no pre-generated core file for this target" > +} It was pointed out to me that after reporting 'unsupported', there should be a return. Without the return we end up seeing TCL errors because the cf_name variable is not defined. Fixed with the patch below, which I have gone ahead and pushed. Thanks, Andrew --- commit 44c8334f4af5b9895d196077f23e20e15eff4c03 Author: Andrew Burgess Date: Mon Jul 10 12:05:21 2023 +0100 gdb/testsuite: return after reporting a test unsupported In this commit: commit 8bcead69665af3a9f9867cd34c3a1daf22120027 Date: Tue May 23 11:25:01 2023 +0100 gdb/testsuite: add test for core file with a 0 pid a new test gdb.arch/core-file-pid0.exp was added. This test includes a pre-generated core file for x86-64 and for other architectures the test reports 'unsupported'. However, after reporting 'unsupported' the test failed to perform an early return, so the test would then carry on and try to actually perform the test, which resulted in some TCL errors. Fix this by returning after reporting the test unsupported. diff --git a/gdb/testsuite/gdb.arch/core-file-pid0.exp b/gdb/testsuite/gdb.arch/core-file-pid0.exp index 56746cca567..46b8c6db5ed 100644 --- a/gdb/testsuite/gdb.arch/core-file-pid0.exp +++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp @@ -28,6 +28,7 @@ if {[istarget "x86_64-*-linux*"]} { set cf_size 8757248 } else { unsupported "no pre-generated core file for this target" + return -1 } # Decompress the core file.