public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Aditya Kamath <Aditya.Kamath1@ibm.com>
To: Aditya Vidyadhar Kamath <akamath996@gmail.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	SANGAMESH MALLAYYA <sangamesh.swamy@in.ibm.com>
Subject: Re:  [PATCH] Fix AIX core dump while main thread exits.
Date: Mon, 28 Oct 2024 10:34:31 +0000	[thread overview]
Message-ID: <CH2PR15MB35441AAF59F7C944CB190659D64A2@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <20241028102610.3305-1-akamath996@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6352 bytes --]

Respected community members,

Hi,

This is a patch to fix a core dump that occurred while we were debugging threads using GDB in AIX.

Kindly give me feedback for the same.

Thanks and regards,
Aditya.

From: Aditya Vidyadhar Kamath <akamath996@gmail.com>
Date: Monday, 28 October 2024 at 3:57 PM
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: gdb-patches@sourceware.org <gdb-patches@sourceware.org>, Aditya Kamath <Aditya.Kamath1@ibm.com>, SANGAMESH MALLAYYA <sangamesh.swamy@in.ibm.com>, Aditya Kamath <Aditya.Kamath1@ibm.com>
Subject: [EXTERNAL] [PATCH] Fix AIX core dump while main thread exits.
From: Aditya Vidyadhar Kamath <aditya.kamath1@ibm.com>

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)
--
2.41.0

  reply	other threads:[~2024-10-28 10:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28 10:26 Aditya Vidyadhar Kamath
2024-10-28 10:34 ` Aditya Kamath [this message]
2024-10-28 16:26 ` Ulrich Weigand
2024-10-30  9:09   ` Aditya Kamath
2024-10-30 12:56     ` Ulrich Weigand
2024-11-04  6:33       ` Aditya Kamath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CH2PR15MB35441AAF59F7C944CB190659D64A2@CH2PR15MB3544.namprd15.prod.outlook.com \
    --to=aditya.kamath1@ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=akamath996@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sangamesh.swamy@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).