From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
"simark@simark.ca" <simark@simark.ca>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch
Date: Wed, 23 Nov 2022 18:45:41 +0000 [thread overview]
Message-ID: <CH2PR15MB3544AB7CA50F834387522DB0D60C9@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <5956432ab1e0eedc8f65e01d3793a80ccf3a3a1f.camel@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]
Hi Ulrich,
>static int
>giter_count (struct thread_info *thread, void *countp)
>{
> if (PD_TID (thread->ptid))
> (*(int *) countp)++;
> return 0;
>}
>Maybe that comment is wrong about pthreaddebug not including
>the main thread? Or maybe that changed between AIX versions?
>In any case, something needs to be fixed here.
Even if we fix it here [assuming we are succesful], in the delete_thread_1 () in thread.c we will fail to hit thread->deletable as true while we attempt delete_thread (gbuf [gi]).. Because refcount will not be 0 when we attempt to delete main thread with ptid (pid, 0, 0). {see func below}
bool
thread_info::deletable () const
{
/* If this is the current thread, or there's code out there that
relies on it existing (refcount > 0) we can't delete yet. */
return refcount () == 0 && !is_current_thread (this);
}
I will be trying to replace the main thread instead like thread_change_ptid (proc_target, gptid, pptid) subject to a condition check that gptid.tid () == 0.. Otherwise, if it is not a main thread [gptid.tid () != 0], we can delete gbuf[gi].. We can apply this else where as well in sync_threadlists ().
Let me know if we have an alternate optimal option that can delete this thread or why the solution in the above paragraph can fail..
Rest of the things I will handle. No problem.
Thanks and regards,
Aditya..
________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 23 November 2022 22:39
To: simark@simark.ca <simark@simark.ca>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:
>Hmm. So, something is going wrong here..
>gcount = 0;
> iterate_over_threads (giter_count, &gcount);
> g = gbuf = XNEWVEC (struct thread_info *, gcount);
> iterate_over_threads (giter_accum, &g);
> qsort (gbuf, gcount, sizeof *gbuf, gcmp);
Looks like this is deliberate:
/* iterate_over_threads() callback for counting GDB threads.
Do not count the main thread (whose tid is zero). This matches
the list of threads provided by the pthreaddebug library, which
does not include that main thread either, and thus allows us
to compare the two lists. */
static int
giter_count (struct thread_info *thread, void *countp)
{
if (PD_TID (thread->ptid))
(*(int *) countp)++;
return 0;
}
Maybe that comment is wrong about pthreaddebug not including
the main thread? Or maybe that changed between AIX versions?
In any case, something needs to be fixed here.
Bye,
Ulrich
next prev parent reply other threads:[~2022-11-23 18:45 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 6:47 Aditya Kamath1
2022-10-28 9:49 ` Ulrich Weigand
2022-11-08 12:00 ` Aditya Kamath1
2022-11-08 12:17 ` Ulrich Weigand
2022-11-13 18:15 ` Aditya Kamath1
2022-11-15 18:16 ` Ulrich Weigand
2022-11-21 8:27 ` Aditya Kamath1
2022-11-23 14:15 ` Ulrich Weigand
2022-11-23 16:03 ` Aditya Kamath1
2022-11-23 17:09 ` Ulrich Weigand
2022-11-23 18:45 ` Aditya Kamath1 [this message]
2022-11-29 8:18 ` Aditya Kamath1
2022-11-30 14:57 ` Ulrich Weigand
2022-12-02 7:50 ` Aditya Kamath1
2022-12-05 18:33 ` Ulrich Weigand
2022-12-08 10:28 ` Aditya Kamath1
2022-12-08 10:46 ` Aditya Kamath1
2022-12-08 16:29 ` Ulrich Weigand
2022-12-15 12:58 ` Aditya Kamath1
2022-12-15 15:53 ` Ulrich Weigand
2022-12-19 6:30 ` Aditya Kamath1
2022-12-22 12:50 ` Ulrich Weigand
2022-12-26 13:18 ` Aditya Kamath1
2023-01-09 14:04 ` Ulrich Weigand
2023-01-10 12:23 ` Aditya Kamath1
2023-01-11 13:31 ` Ulrich Weigand
2023-01-13 14:06 ` Aditya Kamath1
2023-01-20 14:44 ` Ulrich Weigand
2023-01-27 14:40 ` Aditya Kamath1
2023-01-30 19:54 ` Tom Tromey
2023-02-02 6:24 ` Aditya Kamath1
2023-02-02 6:35 ` Aditya Kamath1
2023-02-02 17:43 ` Ulrich Weigand
2023-02-03 11:10 ` Aditya Kamath1
2023-02-06 19:07 ` Ulrich Weigand
2023-02-07 11:57 ` Aditya Kamath1
2023-02-08 18:44 ` Ulrich Weigand
2023-02-10 16:33 ` Aditya Kamath1
2023-02-10 16:46 ` Aditya Kamath1
2023-02-13 19:01 ` Ulrich Weigand
2023-02-14 14:13 ` Aditya Kamath1
2023-02-16 19:46 ` Ulrich Weigand
2023-02-17 11:26 ` Aditya Kamath1
2023-02-17 12:04 ` Ulrich Weigand
2023-02-17 13:22 ` Aditya Kamath1
2023-02-17 14:18 ` Ulrich Weigand
2023-02-17 15:15 ` Aditya Kamath1
2023-02-17 19:14 ` Ulrich Weigand
2022-11-08 12:00 Aditya Kamath1
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=CH2PR15MB3544AB7CA50F834387522DB0D60C9@CH2PR15MB3544.namprd15.prod.outlook.com \
--to=aditya.kamath1@ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=sangamesh.swamy@in.ibm.com \
--cc=simark@simark.ca \
/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).