From patchwork Mon Oct 28 10:26:11 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aditya Vidyadhar Kamath X-Patchwork-Id: 99697 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EBDF53858C60 for ; Mon, 28 Oct 2024 10:28:05 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id D9ABD3858D26 for ; Mon, 28 Oct 2024 10:27:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9ABD3858D26 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D9ABD3858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::22f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730111264; cv=none; b=krimIMI8+UWe1+96CHZkGB70Xa1HqwAaLHDEFi5ibRt/1jX1iW/aumu6VfhKkVVZmZ7PTY0CNk2dCILKAIdUEJFhXrLAoFHojY9AO+dKIqKhaKnYL1goY8rcP1rEWM/iRq2vH2A2mM7yQZLbzns5ISLY3J0pS7WHBNxYX5GOaAM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730111264; c=relaxed/simple; bh=4Cprf+dlZYguyZ7NmUDssL6SW4NZPe5xSz2zajHO2jw=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=XUokhJVF54ZZ4UDHeouoo16LtbBtREvXsfdgtbtCV6yh3GSOxykdGIQ6k2WmCfH7sdd2kls9sb3zK3JFMgJMBQUc/Ql0G6bXTf1POHCMwm+7CPNLR9W543yTndt1cYiXRZLynP8qOxahyeP1xTodUmO/eoUtUNXJuX5Fqv0tozk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x22f.google.com with SMTP id 5614622812f47-3e60e57a322so2401886b6e.3 for ; Mon, 28 Oct 2024 03:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730111255; x=1730716055; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PS+Z0xkfEaHfysJWCjYWUbHz66cjafiWBCFysiCTZVs=; b=VBIlhHJRbmcT4aOlkDgRL00Avle8qd3uwhJhex37gC2T/xvTv9AkLGeOsZ3JFC2Hfy /2KgXeIatIDXiFUvrHkbshebvTKnzMpNOwnZi4ts4O9s5MrVodqf74eisHV+ErMplTR4 yoHeixUBLCR+h9xDfU5Ej4ROimkw7gWYbGjGC62zb9vlSKLmiZYUIx1PCFgUUuw4djrh yC3n/h8F9jTpD7qjRCYWygjkJrgkocBhMsuieJGVJ+Lv190kgqZyAluHjosO0WMAu5ml USEJlybqFGCpS+xm9NHEYrzgko87q7XYK1/lCaeCpM5oHr3WzOXHLcB1+n2DyMQ5TwO0 gV9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730111255; x=1730716055; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PS+Z0xkfEaHfysJWCjYWUbHz66cjafiWBCFysiCTZVs=; b=JtaSDCCo74HYx1LHex9GTQKaU6woXCFjm3MsnO3G/0bP1hOP2zRJ5J7IFnGhtHuYzb IgPV6ckbGLHkqBWhtTrHt6yb+4+pfx7xbejS4KZB7H37UnXwscsrKt+b7fJqmXiof5da f1DXUvPjDMYraaaV61j1gv09fa9Vu0XHLEbUGbIhmNYmy4V5/N76klm6X3gO/lRvzyLd te+XB/iaLaR70zEf/awMNRh4IxdSnAHOMpyNnjBWu30QnUUeNVV4Rtwjb8Ab8AssWgyR qodagRg6QnJe0RnuAtGVKNGvan3BRC7GT2Ka2T7TDHhZKsCP15R7FCIxKfIGMt+MwoDN 4rAw== X-Gm-Message-State: AOJu0Yz8QtKJY2jHySd8ThMXel3kHBtKI+DqunM5iNVm6d6uRZqlm67z 2Q/EjmgwK8hi1JB3vdOJevHDhEYvFXtD4fvK6dWQ0dDN76HteC2/ X-Google-Smtp-Source: AGHT+IFYhnGdmIRpGrXbx/oe6UsX3PSyYofLB//yeO+IW0o2IFFDEojKOl33AO9TmQaxICXiTIuHZA== X-Received: by 2002:a05:6808:399b:b0:3e6:f30:f8ba with SMTP id 5614622812f47-3e6384c4d53mr7049213b6e.29.1730111254949; Mon, 28 Oct 2024 03:27:34 -0700 (PDT) Received: from localhost.localdomain ([122.171.22.178]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7edc8495cabsm5509598a12.0.2024.10.28.03.27.31 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 28 Oct 2024 03:27:33 -0700 (PDT) From: Aditya Vidyadhar Kamath To: ulrich.weigand@de.ibm.com Cc: gdb-patches@sourceware.org, Aditya.Kamath1@ibm.com, sangamesh.swamy@in.ibm.com, Aditya Vidyadhar Kamath Subject: [PATCH] Fix AIX core dump while main thread exits. Date: Mon, 28 Oct 2024 15:56:11 +0530 Message-Id: <20241028102610.3305-1-akamath996@gmail.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) MIME-Version: 1.0 X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~patchwork=sourceware.org@sourceware.org From: Aditya Vidyadhar Kamath Consider the test case: void *thread_main(void *) { std::cout << getpid() << std::endl; sleep(20); return nullptr; } int main(void) { pthread_t thread; pthread_create(&thread, nullptr, thread_main, nullptr); pthread_join(thread, nullptr); return 0; } This program creates a thread via main that sleeps for 20 seconds. When we debug this with gdb we get, Reading symbols from ./test... (gdb) b main Breakpoint 1 at 0x10000934: file test.c, line 11. (gdb) r Starting program: /read_only_gdb/binutils-gdb/gdb/test Breakpoint 1, main () at test.c:11 11 pthread_create(&thread, nullptr, thread_main, nullptr); (gdb) c Continuing. 15335884 [New Thread 258 (tid 31130079)] Thread 2 received signal SIGINT, Interrupt. [Switching to Thread 258 (tid 31130079)] 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) (gdb) thread 1 [Switching to thread 1 (Thread 1 (tid 25493845))] (gdb) c Continuing. [Thread 1 (tid 25493845) exited] [Thread 258 (tid 31130079) exited] inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- There are two bugs here. One is the core dump. The other is the main thread information not captured. So, while I was debugging the first part the reason, the reason I figured out was the last for loop in sync_threadlists (). Once both my threads exit we delete them as below: for (struct thread_info *it : all_threads ()) { if (in_queue_threads.count (priv->pdtid) == 0 && in_thread_list (proc_target, it->ptid) && pid == it->ptid.pid ()) { delete_thread (it); data->exited_threads.insert (priv->pdtid); But once these two threads are deleted, all_threads () has one more thread whose tid and pid are 0. gdb) c Continuing. In for loop 8782296 is pid, 19857879 is tid [Thread 1 (tid 19857879) exited] In for loop 8782296 is pid, 30933401 is tid [Thread 258 (tid 30933401) exited] In for loop 0 is pid, 0 is tid [Inferior 1 (process 8782296) exited normally] (gdb) q I used a printf in the for loop mentioned above for explaination. You see the loop enters the third time with 0 as pid. Hence I proposed this solution to break out of the loop if the process itself has completed execution and hence its pid is 0. Kindly let me know if this is okay. The second part to the bug is the lack of information of the main thread. Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html) Thank you Andrew. The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread failed. This returned EPERM as errno. if (!ptrace32 (PTT_READ_GPRS, tid, (uintptr_t) gprs32, 0, NULL)) memset (gprs32, 0, sizeof (gprs32)); Hence all registers were set to 0 and we did not get the required infromation. (gdb) thread 1 [Switching to thread 1 (Thread 1 (tid 31916423))] (gdb) info registers r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 r13 0x0 0 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0x0 0 r27 0x0 0 r28 0x0 0 r29 0x0 0 r30 0x0 0 r31 0x0 0 pc 0x0 0x0 msr 0x0 0 cr 0x0 0 lr 0x0 0x0 ctr 0x0 0 xer 0x0 0 fpscr 0x0 0 vscr 0x0 0 vrsave 0x0 0 (gdb) c For some reason the main thread is in kernel mode and I am not able to read the register contents for the main thread no matter how we try it. If any other target has faced this type of issue and/or handled this situation differently then kindly let me know. I will also cordinate with kernel folks for potential solutions. Kindly let me know what is your opinion about this patch for atleast the first part. --- gdb/aix-thread.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c index 9e6952b974f..94ad0a2d90a 100644 --- a/gdb/aix-thread.c +++ b/gdb/aix-thread.c @@ -856,6 +856,8 @@ sync_threadlists (pid_t pid) is to manually delete such threads. */ for (struct thread_info *it : all_threads ()) { + if (it->ptid.pid () == 0) + break; aix_thread_info *priv = get_aix_thread_info (it); if (in_queue_threads.count (priv->pdtid) == 0 && in_thread_list (proc_target, it->ptid)