public inbox for
 help / color / mirror / Atom feed
From: Ulrich Weigand <>
To: "" <>,
	Aditya Kamath1 <>,
	"" <>
Cc: Sangamesh Mallayya <>
Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch
Date: Tue, 15 Nov 2022 18:16:01 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Aditya Kamath1 <> wrote:

>>So I think instead of adding a "priv" struct to that GDB thread
>>identifying the main process, the sync_threadlists routine should
>>actually just delete it (or replace it with the actual first thread,
>>whatever is easier).
>I have chosen not to add the first main thread as new thread. Instead,
>we carry on with main process thread itself adding private data to it.
>Kindly see the first if condition. I observed this with the linux folks
>where in their output as you mentioned do not add any new threads the
>first time on recognition of multi thread debugee for the main process.  

OK, but this is still weird:
>* 1    process 26149278                   0xd0595fb0 in _p_nsleep ()
>  2    Thread 258 (tid 24445361, running) thread_function (arg=0x0)
>  3    Thread 515 (tid 16187681, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

Why does the first thread look so different?  That's not the
case with Linux threads.  I believe even if you re-use the
thread structure, you'll still need to switch the ptid to one
that indicates a thread instead of a non-threaded process.

>A couple of things I want to inform you is that the way the second
>for loop is executing is not correct from here on to sync both the
>buffer lists [pthread and GDB thread]. Since we are now not adding
>multiple threads for the same process main thread one representing
>the GDB thread and the other by the pthread those conditions and
>indices like pi and gi will fail. Now there has not pcount - 1
>threads in the GDB thread buffer always. Condition 2 and 3 in the
>patch take care of them for addition and deletion of threads. 

The new logic doesn't look correct to me - note that it never
even looks at thread IDs any more, just the raw number of threads.
So for example if *any* thread exits, the code will always delete
the *last* thread from the GDB list - whether this is actually
the one that exited or not.

I do think it is necessary to compare thread IDs - you need to
map the thread IDs retrieved by libpthdebug against the thread
IDs already present in GDB's thread list.  If a matching thread
ID is present in both lists, it should not be touched.  If a
thread ID occurs only in the libpthdebug list, it needs to be
added to GDB's list.  If a thread ID occurs only in GDB's list,
it needs to be removed from there.

That's what the old code attempted to do as far as I can see;
if it got it wrong in certain corner cases, they need to be fixed;
but completely removing that logic seems just wrong.


  parent reply	other threads:[~2022-11-15 18:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2022-10-28  9:49 ` Ulrich Weigand
     [not found]   ` <>
2022-11-08 12:17     ` Ulrich Weigand
     [not found]       ` <>
2022-11-15 18:16         ` Ulrich Weigand [this message]
     [not found]           ` <>
2022-11-23 14:15             ` Ulrich Weigand
     [not found]               ` <>
2022-11-23 17:09                 ` Ulrich Weigand
     [not found]                   ` <>
     [not found]                     ` <>
2022-11-30 14:57                       ` Ulrich Weigand
     [not found]                         ` <>
2022-12-05 18:33                           ` Ulrich Weigand
     [not found]                             ` <>
2022-12-08 16:29                               ` Ulrich Weigand
     [not found]                                 ` <>
2022-12-15 15:53                                   ` Ulrich Weigand
     [not found]                                     ` <>
2022-12-22 12:50                                       ` Ulrich Weigand
     [not found]                                         ` <>
2023-01-09 14:04                                           ` Ulrich Weigand
     [not found]                                             ` <>
2023-01-11 13:31                                               ` Ulrich Weigand
     [not found]                                                 ` <>
2023-01-20 14:44                                                   ` Ulrich Weigand
     [not found]                                                     ` <>
2023-01-30 19:54                                                       ` Tom Tromey
     [not found] <>
2023-02-02 17:43 ` Ulrich Weigand
     [not found]   ` <>
2023-02-06 19:07     ` Ulrich Weigand
     [not found]       ` <>
2023-02-08 18:44         ` Ulrich Weigand
     [not found]           ` <>
2023-02-13 19:01             ` Ulrich Weigand
     [not found]               ` <>
2023-02-16 19:46                 ` Ulrich Weigand
     [not found]                   ` <>
2023-02-17 12:04                     ` Ulrich Weigand
     [not found]                       ` <>
2023-02-17 14:18                         ` Ulrich Weigand
     [not found]                           ` <>
2023-02-17 19:14                             ` 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:

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

  git send-email \ \ \ \ \ \ \

* 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).