public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: Aditya Kamath1 <Aditya.Kamath1@ibm.com>,
	Aditya Kamath1 via Gdb-patches <gdb-patches@sourceware.org>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [RFC] Using all three fields of ptid and handling thread events from rs6000-aix-nat.c
Date: Mon, 15 Apr 2024 10:36:40 -0700	[thread overview]
Message-ID: <d759d09d-6466-4b13-a25c-ab1e2df3817f@FreeBSD.org> (raw)
In-Reply-To: <CH2PR15MB3544A54C0069F64093476A2BD6092@CH2PR15MB3544.namprd15.prod.outlook.com>

On 4/15/24 7:37 AM, Aditya Kamath1 wrote:
> Respected community members,
> 
> Hi,
> 
> I am currently working on fixing a bug on handling the thread exit event in AIX and displaying the same in UI. Currently, in AIX we miss the event resulting in incorrect display of info threads.
> 
> For example, for the program 1 pasted below this email. This is a single process creating three more threads.
> 
> The GDB output in AIX is:-
> 
> (gdb) b main
> Breakpoint 1 at 0x10000788: file //gdb_tests/continue-pending-status_exit_test.c, line 44.
> (gdb) r
> Starting program: /gdb_tests/continue-pending-status_exit_test
> Breakpoint 1, main () at //gdb_tests/continue-pending-status_exit_test.c:44
> 44        alarm (300);
> (gdb) c
> Hello World
> Hello World
> Hello World
> [New Thread 258]
> [New Thread 515]
> [New Thread 772]
> Thread 1 received signal SIGINT, Interrupt.
> 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
> (gdb) info threads
>    Id   Target Id                                          Frame
> * 1    Thread 1 (tid 26607979) (tid 26607979, running)    0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
>    2    Thread 258 (tid 30998799) (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.)
> 
> The Linux output for the same is
> 
> (gdb) b main
> Breakpoint 1 at 0x10000990: file test_thread.c, line 27.
> (gdb) r
> Starting program: /home/buildusr/binutils-gdb/gdb/test_thread
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 
> Breakpoint 1,
> main () at test_thread.c:27
> 27        alarm (300);
> (gdb) c
> Continuing.
> [New Thread 0x7ffff7c7f170 (LWP 4032543)]
> [New Thread 0x7ffff746f170 (LWP 4032544)]
> [New Thread 0x7ffff6c5f170 (LWP 4032545)]
> Hello World
> Hello World
> Hello World
> [Thread 0x7ffff6c5f170 (LWP 4032545) exited]
> [Thread 0x7ffff746f170 (LWP 4032544) exited]
> [Thread 0x7ffff7c7f170 (LWP 4032543) exited]
> ^C
> Thread 1 "test_thread" received signal SIGINT, Interrupt.
> 0x00007ffff7da5b04 in nanosleep () from /lib64/libc.so.6
> (gdb) info threads
>    Id   Target Id                                         Frame
> * 1    Thread 0x7ffff7ff3e00 (LWP 4032541)
> 0x00007ffff7da5b04 in nanosleep () from /lib64/libc.so.6
> (gdb)
> 
> 
> Reason why this happened.
> 
> In Linux, I see in the linux-nat.c /* Check if the thread has exited.  */
> 2278<https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdb/linux-nat.c;h=2602e1f240d0056b0e199a952d86bbaf96e6d2f3;hb=34d5ac9244ccfe566232469ec3bef1329f0bc42e#l2278>       if (WIFEXITED (status) || WIFSIGNALED (status))
> 2279<https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdb/linux-nat.c;h=2602e1f240d0056b0e199a952d86bbaf96e6d2f3;hb=34d5ac9244ccfe566232469ec3bef1329f0bc42e#l2279>         {
> 
> This is where it gets handled when wait () is called.
> 
> But in AIX, in sync_threadlist () despite having the code we miss the bus. If we observe the sync_threadlists () code our pcount and gcount remain the same despite the threads exiting resulting in, we not capturing the exit.

Even though pcount == gcount, in theory your ptid's should be different in pbuf[]
vs gbuf[].

That said, when I added thread support to FreeBSD (albeit just using LWPs and not
bothering with libthread_db), there in my 'update_thread_list' target I first
call 'prune_threads' which uses the 'target::thread_alive' hook to remove any
threads that are no longer active, and then call a function that does the
equivalent of fetching pbuf[] and adding any threads whose ptid is not already
present (see fbsd_nat.c::fbsd_add_threads).

The approach of using qsort with two sets of lists and comparing the lists should
be correct from what I can tell, but it is also more complex and might be harder
to debug?

> The debugger checks why it had to wait (), goes to pd_activate (), then to pd_update (), then to sync_threadlists () where the event of threads born are captured.
> 
> One interesting thing here is that in Linux the print “Hello World” happens after the thread born event is captured but in AIX it happens before.

Linux raises a ptrace() stop when a new thread is created.  When using libthread_db
I believe you should be placing a breakpoint in your thread library so that you can
capture new threads in userspace before they start executing (e.g. in the internal
routine in your thread library that eventually calls the thread's start routine).

For FreeBSD with LWP-backed threads I ended up just adding a new ptrace event in the
kernel when a new thread starts executing and use that to add threads instead.

In many cases this race wouldn't matter much for users though.

> Are we missing something in AIX?? One information I want to give is we do go to wait () before the print Hello world happens, but we do not call pd_activate () and even if we do [We call it on purpose skipping the if condition in wait () in aix-thread.c], the thread debug session is not successful. In the next wait () event is when we capture the new thread or add_thread () event.
> 
> There is one more wait () event that happens after this, but here as well AIX fails to capture the thread_exit event in sync_threadlists () since the pcount and gcount are the same.

I'm still not sure how we you are missing the thread exit event.  Even though
pcount == gcount it looks like sync_threadlists still walks the two lists using
ptid_cmp so should still DTRT?

-- 
John Baldwin


  reply	other threads:[~2024-04-15 17:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 14:37 Aditya Kamath1
2024-04-15 17:36 ` John Baldwin [this message]
2024-04-17 10:36   ` Aditya Kamath1
2024-04-17 18:48     ` Ulrich Weigand
2024-04-20 20:25     ` John Baldwin
2024-04-16  8:52 ` Ulrich Weigand

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=d759d09d-6466-4b13-a25c-ab1e2df3817f@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=Aditya.Kamath1@ibm.com \
    --cc=Ulrich.Weigand@de.ibm.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).