* Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list
@ 2020-05-28 15:29 Petr Sumbera
2020-05-28 16:01 ` Rainer Orth
2020-06-01 11:39 ` Petr Sumbera
0 siblings, 2 replies; 12+ messages in thread
From: Petr Sumbera @ 2020-05-28 15:29 UTC (permalink / raw)
To: gdb
Hi,
I'm running into the issue below. Any suggestion how to this?
# DISPLAY=:1 gdb /opt/firefox/bin/firefox
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/firefox/bin/firefox...
(gdb) run -P
Starting program: /opt/firefox/bin/firefox -P
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP 2 ]
[New LWP 3 ]
[New LWP 4 ]
[New LWP 5 ]
[New LWP 6 ]
[New LWP 7 ]
[New LWP 8 ]
[New LWP 9 ]
[New LWP 10 ]
[New LWP 11 ]
[New LWP 12 ]
[New LWP 13 ]
[New LWP 14 ]
[New LWP 15 ]
[New LWP 16 ]
[New LWP 17 ]
[New LWP 18 ]
[New LWP 19 ]
[New LWP 20 ]
[New LWP 21 ]
[New LWP 22 ]
[New LWP 23 ]
[New LWP 24 ]
[New LWP 25 ]
[New LWP 26 ]
[LWP 20 exited]
[New LWP 20 ]
[LWP 21 exited]
[New LWP 21 ]
procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list.
procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list.
(gdb)
---
Is this Solaris GDB issue? Any suggestion where to look in GDB code?
Thanks!
Petr
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-05-28 15:29 Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list Petr Sumbera @ 2020-05-28 16:01 ` Rainer Orth 2020-06-01 12:47 ` Petr Sumbera 2020-06-01 11:39 ` Petr Sumbera 1 sibling, 1 reply; 12+ messages in thread From: Rainer Orth @ 2020-05-28 16:01 UTC (permalink / raw) To: Petr Sumbera via Gdb Hi Petr, > I'm running into the issue below. Any suggestion how to this? > > # DISPLAY=:1 gdb /opt/firefox/bin/firefox > GNU gdb (GDB) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.11". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /opt/firefox/bin/firefox... > (gdb) run -P > Starting program: /opt/firefox/bin/firefox -P > [Thread debugging using libthread_db enabled] > [New Thread 1 (LWP 1)] > [New LWP 2 ] [...] > [New LWP 26 ] > [LWP 20 exited] > [New LWP 20 ] > [LWP 21 exited] > [New LWP 21 ] > procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. > procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. > (gdb) > > --- > > Is this Solaris GDB issue? Any suggestion where to look in GDB code? I'm seeing this relatively often when running the gdb testsuite (which makes it unsuitable to run make check on the Solaris gdb buildbots). I haven't yet gotten around to investigate closely, but the first places to check are procfs.c (the process layer, via /proc) and sol-thread.c (the thread layer, via libc_db). There's lots of old cruft in there from pre-Solaris 9 times with its NxM thread model, which both breaks a considerable number of test cases and makes the code harder to follow due to the added complexity/generality we don't need any longer. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-05-28 16:01 ` Rainer Orth @ 2020-06-01 12:47 ` Petr Sumbera 0 siblings, 0 replies; 12+ messages in thread From: Petr Sumbera @ 2020-06-01 12:47 UTC (permalink / raw) To: Rainer Orth, Petr Sumbera via Gdb Hi Rainer, please see my other mail. But it seems to me that handling LWP exit might be broken on Solaris. Though I think I'm really lost and don't know how to continue now. Thanks! Petr On 28.05.2020 18:01, Rainer Orth wrote: > Hi Petr, > >> I'm running into the issue below. Any suggestion how to this? >> >> # DISPLAY=:1 gdb /opt/firefox/bin/firefox >> GNU gdb (GDB) 9.2 >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> Type "show copying" and "show warranty" for details. >> This GDB was configured as "sparc-sun-solaris2.11". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>. >> Find the GDB manual and other documentation resources online at: >> <http://www.gnu.org/software/gdb/documentation/>. >> >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from /opt/firefox/bin/firefox... >> (gdb) run -P >> Starting program: /opt/firefox/bin/firefox -P >> [Thread debugging using libthread_db enabled] >> [New Thread 1 (LWP 1)] >> [New LWP 2 ] > [...] >> [New LWP 26 ] >> [LWP 20 exited] >> [New LWP 20 ] >> [LWP 21 exited] >> [New LWP 21 ] >> procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. >> procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. >> (gdb) >> >> --- >> >> Is this Solaris GDB issue? Any suggestion where to look in GDB code? > > I'm seeing this relatively often when running the gdb testsuite (which > makes it unsuitable to run make check on the Solaris gdb buildbots). > > I haven't yet gotten around to investigate closely, but the first places > to check are procfs.c (the process layer, via /proc) and sol-thread.c > (the thread layer, via libc_db). > > There's lots of old cruft in there from pre-Solaris 9 times with its NxM > thread model, which both breaks a considerable number of test cases and > makes the code harder to follow due to the added complexity/generality > we don't need any longer. > > Rainer > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-05-28 15:29 Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list Petr Sumbera 2020-05-28 16:01 ` Rainer Orth @ 2020-06-01 11:39 ` Petr Sumbera 2020-06-01 19:12 ` Pedro Alves 1 sibling, 1 reply; 12+ messages in thread From: Petr Sumbera @ 2020-06-01 11:39 UTC (permalink / raw) To: gdb The issue seems to be that the LWP exits and the status->kind is set to TARGET_WAITKIND_SPURIOUS: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/procfs.c;h=f6c6b0e71c16224d3e7345ca09e011cdcf06349a;hb=HEAD#l2214 But instantly it's added into the list again here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/infrun.c;h=95fc3bfe45930b53c33cb4de165db9c070449ad8;hb=HEAD#l5200 But there is no longer such LWP in /proc. Any suggestion? Thanks, Petr On 28.05.2020 17:29, Petr Sumbera via Gdb wrote: > Hi, > > I'm running into the issue below. Any suggestion how to this? > > # DISPLAY=:1 gdb /opt/firefox/bin/firefox > GNU gdb (GDB) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.11". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /opt/firefox/bin/firefox... > (gdb) run -P > Starting program: /opt/firefox/bin/firefox -P > [Thread debugging using libthread_db enabled] > [New Thread 1 (LWP 1)] > [New LWP 2 ] > [New LWP 3 ] > [New LWP 4 ] > [New LWP 5 ] > [New LWP 6 ] > [New LWP 7 ] > [New LWP 8 ] > [New LWP 9 ] > [New LWP 10 ] > [New LWP 11 ] > [New LWP 12 ] > [New LWP 13 ] > [New LWP 14 ] > [New LWP 15 ] > [New LWP 16 ] > [New LWP 17 ] > [New LWP 18 ] > [New LWP 19 ] > [New LWP 20 ] > [New LWP 21 ] > [New LWP 22 ] > [New LWP 23 ] > [New LWP 24 ] > [New LWP 25 ] > [New LWP 26 ] > [LWP 20 exited] > [New LWP 20 ] > [LWP 21 exited] > [New LWP 21 ] > procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. > procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. > (gdb) > > --- > > Is this Solaris GDB issue? Any suggestion where to look in GDB code? > > Thanks! > > Petr ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-01 11:39 ` Petr Sumbera @ 2020-06-01 19:12 ` Pedro Alves 2020-06-02 7:32 ` Petr Sumbera 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-01 19:12 UTC (permalink / raw) To: Petr Sumbera, gdb On 6/1/20 12:39 PM, Petr Sumbera via Gdb wrote: > The issue seems to be that the LWP exits and the status->kind is set to TARGET_WAITKIND_SPURIOUS: > > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/procfs.c;h=f6c6b0e71c16224d3e7345ca09e011cdcf06349a;hb=HEAD#l2214 > > But instantly it's added into the list again here: > > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/infrun.c;h=95fc3bfe45930b53c33cb4de165db9c070449ad8;hb=HEAD#l5200 > > But there is no longer such LWP in /proc. > > Any suggestion? Either: - replace TARGET_WAITKIND_SPURIOUS with TARGET_WAITKIND_THREAD_EXITED, or, - replace status->kind = TARGET_WAITKIND_SPURIOUS; return retval; with goto wait_again; instead. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-01 19:12 ` Pedro Alves @ 2020-06-02 7:32 ` Petr Sumbera 2020-06-02 14:53 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Petr Sumbera @ 2020-06-02 7:32 UTC (permalink / raw) To: Pedro Alves, gdb On 01.06.2020 21:12, Pedro Alves wrote: > On 6/1/20 12:39 PM, Petr Sumbera via Gdb wrote: >> The issue seems to be that the LWP exits and the status->kind is set to TARGET_WAITKIND_SPURIOUS: >> >> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/procfs.c;h=f6c6b0e71c16224d3e7345ca09e011cdcf06349a;hb=HEAD#l2214 >> >> But instantly it's added into the list again here: >> >> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/infrun.c;h=95fc3bfe45930b53c33cb4de165db9c070449ad8;hb=HEAD#l5200 >> >> But there is no longer such LWP in /proc. >> >> Any suggestion? Thanks for looking at it! > Either: > > - replace TARGET_WAITKIND_SPURIOUS with TARGET_WAITKIND_THREAD_EXITED, or, With this I'm getting: [LWP 21 exited] [LWP 21 exited] /builds/psumbera/userland-gdb-procinfo/components/gdb/gdb-9.2/gdb/thread.c:459: internal-error: void delete_thread_1(thread_info*, bool): Assertion `thr != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. > - replace > status->kind = TARGET_WAITKIND_SPURIOUS; > return retval; > with > goto wait_again; > instead. and with this: [LWP 20 exited] [LWP 20 exited] /builds/psumbera/userland-gdb-procinfo/components/gdb/gdb-9.2/gdb/thread.c:459: internal-error: void delete_thread_1(thread_info*, bool): Assertion `thr != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. -- Note that in both cases there are TWO exits for one LWP. But LWP numbers differ. Any other comment? Thanks! Petr ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-02 7:32 ` Petr Sumbera @ 2020-06-02 14:53 ` Pedro Alves 2020-06-02 16:30 ` Petr Sumbera 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-02 14:53 UTC (permalink / raw) To: Petr Sumbera, gdb On 6/2/20 8:32 AM, Petr Sumbera via Gdb wrote: > On 01.06.2020 21:12, Pedro Alves wrote: >> On 6/1/20 12:39 PM, Petr Sumbera via Gdb wrote: >>> The issue seems to be that the LWP exits and the status->kind is set to TARGET_WAITKIND_SPURIOUS: >>> >>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/procfs.c;h=f6c6b0e71c16224d3e7345ca09e011cdcf06349a;hb=HEAD#l2214 >>> >>> But instantly it's added into the list again here: >>> >>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/infrun.c;h=95fc3bfe45930b53c33cb4de165db9c070449ad8;hb=HEAD#l5200 >>> >>> But there is no longer such LWP in /proc. >>> >>> Any suggestion? > > Thanks for looking at it! > >> Either: >> >> - replace TARGET_WAITKIND_SPURIOUS with TARGET_WAITKIND_THREAD_EXITED, or, > > With this I'm getting: > > [LWP 21 exited] > [LWP 21 exited] > /builds/psumbera/userland-gdb-procinfo/components/gdb/gdb-9.2/gdb/thread.c:459: internal-error: void delete_thread_1(thread_info*, bool): Assertion `thr != nullptr' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > >> - replace >> status->kind = TARGET_WAITKIND_SPURIOUS; >> return retval; >> with >> goto wait_again; >> instead. > > and with this: > > [LWP 20 exited] > [LWP 20 exited] > /builds/psumbera/userland-gdb-procinfo/components/gdb/gdb-9.2/gdb/thread.c:459: internal-error: void delete_thread_1(thread_info*, bool): Assertion `thr != nullptr' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > -- > > Note that in both cases there are TWO exits for one LWP. But LWP numbers differ. You mean, it was 21 in one run, and 20 in another run? Those were two different runs, and some timing difference probably tweaked the order of which thread exits first or something. Doesn't seem unusual. Sounds like the patch below would fix it. But why do we get two exits in a row for each LWP? Oh, I guess once for PR_SYSENTRY of the exit syscall, and another time for PR_SYSEXIT. From 0be6c82e754dd676e9f1259ab0f9a7849d985ffd Mon Sep 17 00:00:00 2001 From: Pedro Alves <pedro@palves.net> Date: Tue, 2 Jun 2020 15:44:54 +0100 Subject: [PATCH] fix-solaris --- gdb/procfs.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gdb/procfs.c b/gdb/procfs.c index f6c6b0e71c1..e2042f3edc4 100644 --- a/gdb/procfs.c +++ b/gdb/procfs.c @@ -2331,9 +2331,10 @@ procfs_target::wait (ptid_t ptid, struct target_waitstatus *status, if (print_thread_events) printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (retval).c_str ()); - delete_thread (find_thread_ptid (this, retval)); - status->kind = TARGET_WAITKIND_SPURIOUS; - return retval; + thread_info *thr = find_thread_ptid (this, retval); + if (thr != nullptr) + delete_thread (thr); + goto wait_again; } else if (0) { base-commit: f6eee2d098049afd18f90b8f4bb6a5d1a49d900c -- 2.14.5 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-02 14:53 ` Pedro Alves @ 2020-06-02 16:30 ` Petr Sumbera 2020-06-02 17:14 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Petr Sumbera @ 2020-06-02 16:30 UTC (permalink / raw) To: Pedro Alves, gdb On 02.06.2020 16:53, Pedro Alves wrote: > On 6/2/20 8:32 AM, Petr Sumbera via Gdb wrote: >> On 01.06.2020 21:12, Pedro Alves wrote: >>> On 6/1/20 12:39 PM, Petr Sumbera via Gdb wrote: >>>> The issue seems to be that the LWP exits and the status->kind is set to TARGET_WAITKIND_SPURIOUS: >>>> >>>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/procfs.c;h=f6c6b0e71c16224d3e7345ca09e011cdcf06349a;hb=HEAD#l2214 >>>> >>>> But instantly it's added into the list again here: >>>> >>>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/infrun.c;h=95fc3bfe45930b53c33cb4de165db9c070449ad8;hb=HEAD#l5200 >>>> >>>> But there is no longer such LWP in /proc. >>>> >>>> Any suggestion? >> >> Thanks for looking at it! >> >>> Either: >>> >>> - replace TARGET_WAITKIND_SPURIOUS with TARGET_WAITKIND_THREAD_EXITED, or, >> >> With this I'm getting: >> >> [LWP 21 exited] >> [LWP 21 exited] >> /builds/psumbera/userland-gdb-procinfo/components/gdb/gdb-9.2/gdb/thread.c:459: internal-error: void delete_thread_1(thread_info*, bool): Assertion `thr != nullptr' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> >>> - replace >>> status->kind = TARGET_WAITKIND_SPURIOUS; >>> return retval; >>> with >>> goto wait_again; >>> instead. >> >> and with this: >> >> [LWP 20 exited] >> [LWP 20 exited] >> /builds/psumbera/userland-gdb-procinfo/components/gdb/gdb-9.2/gdb/thread.c:459: internal-error: void delete_thread_1(thread_info*, bool): Assertion `thr != nullptr' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> >> -- >> >> Note that in both cases there are TWO exits for one LWP. But LWP numbers differ. > > You mean, it was 21 in one run, and 20 in another run? > Those were two different runs, and some timing difference > probably tweaked the order of which thread exits first or > something. Doesn't seem unusual. > > Sounds like the patch below would fix it. Unfortunately no. > But why do we get two exits in a row for each LWP? Oh, I guess > once for PR_SYSENTRY of the exit syscall, and another time for > PR_SYSEXIT. Only PR_SYSENTRY is called for my test case (the first occurrence of 'exited]' - I changed that strings to distinguish between each other). > From 0be6c82e754dd676e9f1259ab0f9a7849d985ffd Mon Sep 17 00:00:00 2001 > From: Pedro Alves <pedro@palves.net> > Date: Tue, 2 Jun 2020 15:44:54 +0100 > Subject: [PATCH] fix-solaris > > --- > gdb/procfs.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/gdb/procfs.c b/gdb/procfs.c > index f6c6b0e71c1..e2042f3edc4 100644 > --- a/gdb/procfs.c > +++ b/gdb/procfs.c > @@ -2331,9 +2331,10 @@ procfs_target::wait (ptid_t ptid, struct target_waitstatus *status, > if (print_thread_events) > printf_unfiltered (_("[%s exited]\n"), > target_pid_to_str (retval).c_str ()); > - delete_thread (find_thread_ptid (this, retval)); > - status->kind = TARGET_WAITKIND_SPURIOUS; > - return retval; > + thread_info *thr = find_thread_ptid (this, retval); > + if (thr != nullptr) > + delete_thread (thr); > + goto wait_again; > } > else if (0) > { > > base-commit: f6eee2d098049afd18f90b8f4bb6a5d1a49d900c > I have modified your change to gdb 9.2 and to correct occurrence (you have added it to second occurrence of 'exited'): --- ../../gdb-9.2/gdb/procfs.c.orig 2020-06-02 17:10:32.057735432 +0000 +++ ../../gdb-9.2/gdb/procfs.c 2020-06-02 18:02:45.496117117 +0000 @@ -2207,9 +2207,10 @@ if (print_thread_events) printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (retval).c_str ()); - delete_thread (find_thread_ptid (retval)); - status->kind = TARGET_WAITKIND_SPURIOUS; - return retval; + thread_info *thr = find_thread_ptid (retval); + if (thr) + delete_thread (thr); + goto wait_again; } else if (syscall_is_exit (pi, what)) { But this time exited message repeats forever: [LWP 24 exited] [LWP 24 exited] [LWP 24 exited] .. --- Petr ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-02 16:30 ` Petr Sumbera @ 2020-06-02 17:14 ` Pedro Alves 2020-06-03 13:09 ` Petr Sumbera 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-02 17:14 UTC (permalink / raw) To: Petr Sumbera, gdb On 6/2/20 5:30 PM, Petr Sumbera wrote: > I have modified your change to gdb 9.2 and to correct occurrence (you have added it to second occurrence of 'exited'): > > --- ../../gdb-9.2/gdb/procfs.c.orig 2020-06-02 17:10:32.057735432 +0000 > +++ ../../gdb-9.2/gdb/procfs.c 2020-06-02 18:02:45.496117117 +0000 > @@ -2207,9 +2207,10 @@ > if (print_thread_events) > printf_unfiltered (_("[%s exited]\n"), > target_pid_to_str (retval).c_str ()); > - delete_thread (find_thread_ptid (retval)); > - status->kind = TARGET_WAITKIND_SPURIOUS; > - return retval; > + thread_info *thr = find_thread_ptid (retval); > + if (thr) > + delete_thread (thr); > + goto wait_again; > } > else if (syscall_is_exit (pi, what)) > { > > But this time exited message repeats forever: > > [LWP 24 exited] > [LWP 24 exited] > [LWP 24 exited] Sounds like the LWP is stuck with the status, or the status is cached. We probably need to resume the process to move it out of the syscall, I guess. There's this bit in the file, at another spot we call goto wait_again: /* How to keep going without returning to wfi: */ target_continue_no_signal (ptid); goto wait_again; wfi == wait_for_inferior, the name of a function that used to be pretty core in infrun.c. Nowadays handle_inferior_event took the role. Try doing the same. Like: delete_thread (find_thread_ptid (this, retval)); target_continue_no_signal (ptid); goto wait_again; You may need to split the delete_thread/find_thread bits, or you may not. I'm not sure. The TARGET_WAITKIND_SPURIOUS handling in infrun.c also just calls resume(GDB_SIGNAL_0), so I _think_ this will work as well as before. I have no idea how this was supposed to handle the case of an LWP exiting while another one is single stepping. Looks like we lose the original single-stepping request. Maybe. Not sure. But doesn't look like we're making things any worse. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-02 17:14 ` Pedro Alves @ 2020-06-03 13:09 ` Petr Sumbera 2020-06-08 9:51 ` Petr Sumbera 0 siblings, 1 reply; 12+ messages in thread From: Petr Sumbera @ 2020-06-03 13:09 UTC (permalink / raw) To: Pedro Alves, gdb On 02.06.2020 19:14, Pedro Alves wrote: > On 6/2/20 5:30 PM, Petr Sumbera wrote: > >> I have modified your change to gdb 9.2 and to correct occurrence (you have added it to second occurrence of 'exited'): >> >> --- ../../gdb-9.2/gdb/procfs.c.orig 2020-06-02 17:10:32.057735432 +0000 >> +++ ../../gdb-9.2/gdb/procfs.c 2020-06-02 18:02:45.496117117 +0000 >> @@ -2207,9 +2207,10 @@ >> if (print_thread_events) >> printf_unfiltered (_("[%s exited]\n"), >> target_pid_to_str (retval).c_str ()); >> - delete_thread (find_thread_ptid (retval)); >> - status->kind = TARGET_WAITKIND_SPURIOUS; >> - return retval; >> + thread_info *thr = find_thread_ptid (retval); >> + if (thr) >> + delete_thread (thr); >> + goto wait_again; >> } >> else if (syscall_is_exit (pi, what)) >> { >> >> But this time exited message repeats forever: >> >> [LWP 24 exited] >> [LWP 24 exited] >> [LWP 24 exited] > > Sounds like the LWP is stuck with the status, or the status is > cached. We probably need to resume the process to move it out > of the syscall, I guess. There's this bit in the file, at > another spot we call goto wait_again: > > /* How to keep going without returning to wfi: */ > target_continue_no_signal (ptid); > goto wait_again; > > wfi == wait_for_inferior, the name of a function that used > to be pretty core in infrun.c. Nowadays handle_inferior_event > took the role. > > Try doing the same. Like: > > delete_thread (find_thread_ptid (this, retval)); > target_continue_no_signal (ptid); > goto wait_again; > > You may need to split the delete_thread/find_thread bits, or > you may not. I'm not sure. > > The TARGET_WAITKIND_SPURIOUS handling in infrun.c also > just calls resume(GDB_SIGNAL_0), so I _think_ this will work as > well as before. I have no idea how this was supposed to handle > the case of an LWP exiting while another one is single > stepping. Looks like we lose the original single-stepping > request. Maybe. Not sure. But doesn't look like we're > making things any worse. This time it looks very promising. This is gdb 9.2 patch: --- gdb-9.2/gdb/procfs.c +++ gdb-9.2/gdb/procfs.c @@ -2208,8 +2208,8 @@ printf_unfiltered (_("[%s exited]\n"), target_pid_to_str (retval).c_str ()); delete_thread (find_thread_ptid (retval)); - status->kind = TARGET_WAITKIND_SPURIOUS; - return retval; + target_continue_no_signal (ptid); + goto wait_again; } else if (syscall_is_exit (pi, what)) { This works for few test cases. And I actually started gdb tests to see if it makes any regression (but it might take some time to run it though). But in one particular case it returns following: .. [LWP 33 exited1] [LWP 31 exited1] [LWP 32 exited1] [LWP 28 exited1] [LWP 30 exited1] [LWP 2 exited1] sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to satisfy query (gdb) It might be related... Thank you very much! Petr ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-03 13:09 ` Petr Sumbera @ 2020-06-08 9:51 ` Petr Sumbera 2020-06-08 13:47 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Petr Sumbera @ 2020-06-08 9:51 UTC (permalink / raw) To: gdb, Pedro Alves [-- Attachment #1: Type: text/plain, Size: 1453 bytes --] On 03.06.2020 15:09, Petr Sumbera via Gdb wrote: > This works for few test cases. And I actually started gdb tests to see > if it makes any regression (but it might take some time to run it though). GDB tests on Solaris doesn't seem to deterministic. So I cannot confirm for 100% that the patch doesn't cause any regression. Though it rather seems it's not. See attached diff output between runs without and with the patch. Can we get the patch to upstream now? > But in one particular case it returns following: > > .. > [LWP 33 exited1] > [LWP 31 exited1] > [LWP 32 exited1] > [LWP 28 exited1] > [LWP 30 exited1] > [LWP 2 exited1] > sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to > satisfy query > sol_thread_fetch_registers: td_ta_map_id2thr: no thread can be found to > satisfy query > (gdb) > > It might be related... Not sure about this one. I see this when I start Firefox with -P and select a profile and Firefox is going to start with selected profile. All threads are closed. The message is for the only remaining thread #1 (after it got TD_NOTHR from p_td_ta_map_id2thr(). Where GDB for some reasons thinks it's 'defunct'. When I run it without GDB the same process will start many other threads and Firefox works. In GDB the above message is shown... Thanks, Petr [-- Attachment #2: test-64-diffs --] [-- Type: text/plain, Size: 21659 bytes --] --- /builds/psumbera/userland-gdb-procinfo/components/gdb/test/results-sparc-64.master 2020-05-28 17:03:56.678546282 +0000 +++ /builds/psumbera/userland-gdb-procinfo/components/gdb/build/test/sparcv9/results-64.snapshot 2020-06-06 03:49:21.031338603 +0000 @@ -2268,37 +2268,42 @@ PASS: gdb.base/batch-exit-status.exp: -batch -x good-commands -ex "set not-a-thing 4": [lindex $result 2] == 0 PASS: gdb.base/batch-exit-status.exp: -batch -x good-commands -ex "set not-a-thing 4": [lindex $result 3] == $expect_status PASS: gdb.base/batch-preserve-term-settings.exp: batch run: spawn shell -PASS: gdb.base/batch-preserve-term-settings.exp: batch run: stty before (not found) +PASS: gdb.base/batch-preserve-term-settings.exp: batch run: stty before PASS: gdb.base/batch-preserve-term-settings.exp: batch run: gdb -batch -ex run FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: echo test_echo (timeout) -UNSUPPORTED: gdb.base/batch-preserve-term-settings.exp: batch run: terminal settings preserved (no stty) +PASS: gdb.base/batch-preserve-term-settings.exp: batch run: stty after +FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: terminal settings preserved PASS: gdb.base/batch-preserve-term-settings.exp: batch run: exit shell PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: spawn shell -PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: stty before (not found) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: stty before PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: start gdb PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: quit gdb -UNSUPPORTED: gdb.base/batch-preserve-term-settings.exp: cli exit: terminal settings preserved (no stty) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: stty after +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: terminal settings preserved PASS: gdb.base/batch-preserve-term-settings.exp: cli exit: exit shell PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: spawn shell -PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: stty before (not found) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: stty before PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: start gdb PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: run command start PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: quit gdb -UNSUPPORTED: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: terminal settings preserved (no stty) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: stty after +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: terminal settings preserved PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after start cmd: exit shell PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: spawn shell -PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: stty before (not found) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: stty before PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: start gdb PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: run command run PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: quit gdb -UNSUPPORTED: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: terminal settings preserved (no stty) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: stty after +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: terminal settings preserved PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after run cmd: exit shell PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: spawn shell -PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: stty before (not found) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: stty before PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: start gdb PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: run shell echo $PPID PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: kill gdb with SIGTERM -UNSUPPORTED: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: terminal settings preserved (no stty) +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: stty after +PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: terminal settings preserved PASS: gdb.base/batch-preserve-term-settings.exp: cli exit after SIGTERM: exit shell PASS: gdb.base/bfp-test.exp: continue to breakpoint: return PASS: gdb.base/bfp-test.exp: the original value of b32 is 1.5 @@ -17681,7 +17686,7 @@ UNSUPPORTED: gdb.base/moribund-step.exp: displaced stepping PASS: gdb.base/msym-lang.exp: info func foo PASS: gdb.base/multi-line-starts-subshell.exp: spawn subshell from multi-line -FAIL: gdb.base/multi-line-starts-subshell.exp: shell input works (timeout) +PASS: gdb.base/multi-line-starts-subshell.exp: shell input works PASS: gdb.base/multi-line-starts-subshell.exp: exit shell PASS: gdb.base/multi-line-starts-subshell.exp: gdb input still works PASS: gdb.base/nested-addr.exp: continue to breakpoint: BREAK @@ -53253,8 +53258,8 @@ FAIL: gdb.mi/list-thread-groups-available.exp: list available thread groups with filter (unexpected output) PASS: gdb.mi/list-thread-groups-no-inferior.exp: -list-thread-groups --available PASS: gdb.mi/list-thread-groups-no-inferior.exp: GDB is still alive -PASS: gdb.mi/mi-async-run.exp: send interrupt command -FAIL: gdb.mi/mi-async-run.exp: expect interrupt (timeout) +FAIL: gdb.mi/mi-async-run.exp: send interrupt command (unexpected output) +FAIL: gdb.mi/mi-async-run.exp: expect interrupt (unknown output after running) PASS: gdb.mi/mi-basics.exp: acceptance of MI operations PASS: gdb.mi/mi-basics.exp: file-exec-and-symbols operation PASS: gdb.mi/mi-basics.exp: file-exec-file operation @@ -54442,7 +54447,7 @@ PASS: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: out of scope now, not changed PASS: gdb.mi/mi-var-cmd.exp: breakpoint at do_locals_tests PASS: gdb.mi/mi-var-cmd.exp: mi runto do_locals_tests -PASS: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now +FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now (unexpected output) PASS: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now, not changed PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:19 (set breakpoint) PASS: gdb.mi/mi-var-cp.exp: create varobj for rx @@ -55459,7 +55464,7 @@ PASS: gdb.mi/new-ui-mi-sync.exp: sync-command=run: add-inferior FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=run: interrupt on the CLI (timeout) FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=run: got MI interrupt output (unknown output after running) -FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=run: got -thread-info output and thread is stopped (unexpected output) +FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=run: got -thread-info output and thread is stopped (timeout) FAIL: gdb.mi/new-ui-mi-sync.exp: sync-command=continue: breakpoint at main (unexpected output) PASS: gdb.mi/new-ui-mi-sync.exp: sync-command=continue: mi runto main PASS: gdb.mi/new-ui-mi-sync.exp: sync-command=continue: send synchronous execution command @@ -60326,8 +60331,8 @@ PASS: gdb.threads/kill.exp: non-threaded: continue to breakpoint: break here PASS: gdb.threads/kill.exp: non-threaded: kill PASS: gdb.threads/killed.exp: successfully compiled posix threads test case -UNRESOLVED: gdb.threads/killed.exp: run program to completion -UNRESOLVED: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily +PASS: gdb.threads/killed.exp: run program to completion +PASS: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily PASS: gdb.threads/leader-exit.exp: successfully compiled posix threads test case PASS: gdb.threads/leader-exit.exp: continue to breakpoint: break-here FAIL: gdb.threads/leader-exit.exp: single thread has been left @@ -60337,12 +60342,13 @@ PASS: gdb.threads/manythreads.exp: set print sevenbit-strings PASS: gdb.threads/manythreads.exp: shell stty intr '^C' PASS: gdb.threads/manythreads.exp: first continue -UNRESOLVED: gdb.threads/manythreads.exp: stop threads 1 -UNRESOLVED: gdb.threads/manythreads.exp: info threads -UNRESOLVED: gdb.threads/manythreads.exp: give a name to the thread -UNRESOLVED: gdb.threads/manythreads.exp: check thread name -UNRESOLVED: gdb.threads/manythreads.exp: second continue -UNRESOLVED: gdb.threads/manythreads.exp: check for duplicate SIGINT +FAIL: gdb.threads/manythreads.exp: stop threads 1 (timeout) +FAIL: gdb.threads/manythreads.exp: info threads (timeout) +FAIL: gdb.threads/manythreads.exp: give a name to the thread (timeout) +FAIL: gdb.threads/manythreads.exp: check thread name (timeout) +FAIL: gdb.threads/manythreads.exp: second continue (timeout) +PASS: gdb.threads/manythreads.exp: check for duplicate SIGINT +UNRESOLVED: gdb.threads/manythreads.exp: stop threads 2 UNRESOLVED: gdb.threads/manythreads.exp: GDB exits after stopping multithreaded program PASS: gdb.threads/multi-create-ns-info-thr.exp: successfully compiled posix threads test case PASS: gdb.threads/multi-create-ns-info-thr.exp: set pagination off @@ -60350,36 +60356,36 @@ PASS: gdb.threads/multi-create.exp: successfully compiled posix threads test case PASS: gdb.threads/multi-create.exp: continue to breakpoint 0 PASS: gdb.threads/multi-create.exp: continue to breakpoint 1 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 2 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 3 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 4 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 5 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 6 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 7 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 8 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 9 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 10 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 11 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 12 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 13 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 14 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 15 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 16 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 17 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 18 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 19 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 20 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 21 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 22 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 23 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 24 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 25 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 26 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 27 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 28 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 29 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 30 -UNRESOLVED: gdb.threads/multi-create.exp: continue to breakpoint 31 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 2 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 3 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 4 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 5 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 6 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 7 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 8 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 9 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 10 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 11 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 12 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 13 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 14 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 15 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 16 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 17 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 18 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 19 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 20 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 21 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 22 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 23 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 24 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 25 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 26 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 27 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 28 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 29 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 30 +FAIL: gdb.threads/multi-create.exp: continue to breakpoint 31 PASS: gdb.threads/multiple-step-overs.exp: successfully compiled posix threads test case PASS: gdb.threads/multiple-step-overs.exp: displaced=off: step: setup: set displaced-stepping off PASS: gdb.threads/multiple-step-overs.exp: displaced=off: step: setup: continue to breakpoint: run to breakpoint @@ -60614,9 +60620,9 @@ PASS: gdb.threads/no-unwaited-for-left.exp: disable scheduler-locking, letting new thread start PASS: gdb.threads/no-unwaited-for-left.exp: continue to breakpoint: break-here-2 PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread -FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits +FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (the program exited) FAIL: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated -PASS: gdb.threads/no-unwaited-for-left.exp: thread apply all with exited thread +FAIL: gdb.threads/no-unwaited-for-left.exp: thread apply all with exited thread PASS: gdb.threads/non-ldr-exc-1.exp: successfully compiled posix threads test case PASS: gdb.threads/non-ldr-exc-1.exp: lock-sched=off,non-stop=on: continue to breakpoint: break-here PASS: gdb.threads/non-ldr-exc-1.exp: lock-sched=off,non-stop=on: thread 2 @@ -60793,8 +60799,8 @@ PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num KFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print i (PRMS: gdb/22214) KFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print j (PRMS: gdb/22214) -PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l -PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k +XFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l +XFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: continue to breakpoint: at printf PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: get valueof "num" PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: get valueof "inner_num" @@ -60802,14 +60808,14 @@ PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num KFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print i (PRMS: gdb/22214) KFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print j (PRMS: gdb/22214) -XFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print l -XFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print k +PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print l +PASS: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print k PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: continue to breakpoint: at printf PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: get valueof "num" PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print num -KFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i (PRMS: gdb/22214) -KFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j (PRMS: gdb/22214) +PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i +PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print l PASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print k PASS: gdb.threads/pending-step.exp: successfully compiled posix threads test case @@ -60850,7 +60856,7 @@ FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: detach: continue to breakpoint: _exit PASS: gdb.threads/process-dies-while-detaching.exp: single-process: detach: detach: detach PASS: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: watch globalvar -FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: continue to breakpoint: _exit +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: continue to breakpoint: _exit (timeout) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: detach PASS: gdb.threads/process-dies-while-detaching.exp: single-process: detach: killed outside: set breakpoint always-inserted on FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: killed outside: continue to breakpoint: _exit @@ -60860,7 +60866,7 @@ FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: detach: continue to breakpoint: _exit FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: detach: continue PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: watch globalvar -FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue to breakpoint: _exit (timeout) +FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue to breakpoint: _exit PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: set breakpoint always-inserted on FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: killed outside: continue to breakpoint: _exit @@ -61499,12 +61505,13 @@ FAIL: gdb.threads/threxit-hop-specific.exp: get past the thread specific breakpoint PASS: gdb.threads/tid-reuse.exp: successfully compiled posix threads test case PASS: gdb.threads/tid-reuse.exp: set print thread-events off -FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_count -FAIL: gdb.threads/tid-reuse.exp: get reuse_time -FAIL: gdb.threads/tid-reuse.exp: setting breakpoint at do_nothing_thread_func -FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: do_nothing_thread_func -FAIL: gdb.threads/tid-reuse.exp: setting breakpoint at after_reuse_time -FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time +FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_count (timeout) +FAIL: gdb.threads/tid-reuse.exp: get reuse_time (timeout) +FAIL: gdb.threads/tid-reuse.exp: setting breakpoint at do_nothing_thread_func (timeout) +FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: do_nothing_thread_func (timeout) +FAIL: gdb.threads/tid-reuse.exp: delete all breakpoints in delete_breakpoints (timeout) +UNRESOLVED: gdb.threads/tid-reuse.exp: setting breakpoint at after_reuse_time (timeout) +FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (timeout) PASS: gdb.threads/tls-core.exp: successfully compiled posix threads test case PASS: gdb.threads/tls-core.exp: gcore PASS: gdb.threads/tls-core.exp: native: load core file @@ -61872,12 +61879,12 @@ PASS: gdb.xml/tdesc-xinclude.exp: set tdesc filename gdb.xml/includes.xml PASS: gdb.xml/tdesc-xinclude.exp: set tdesc filename gdb.xml/bad-include.xml PASS: gdb.xml/tdesc-xinclude.exp: set tdesc filename gdb.xml/loop.xml -# of expected passes 58328 -# of unexpected failures 2818 +# of expected passes 58340 +# of unexpected failures 2856 # of unexpected successes 1 # of expected failures 43 # of unknown successes 7 -# of known failures 89 -# of unresolved testcases 165 +# of known failures 87 +# of unresolved testcases 129 # of untested testcases 94 -# of unsupported tests 337 +# of unsupported tests 332 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list 2020-06-08 9:51 ` Petr Sumbera @ 2020-06-08 13:47 ` Pedro Alves 0 siblings, 0 replies; 12+ messages in thread From: Pedro Alves @ 2020-06-08 13:47 UTC (permalink / raw) To: Petr Sumbera, gdb On 6/8/20 10:51 AM, Petr Sumbera via Gdb wrote: > On 03.06.2020 15:09, Petr Sumbera via Gdb wrote: >> This works for few test cases. And I actually started gdb tests to see if it makes any regression (but it might take some time to run it though). > > GDB tests on Solaris doesn't seem to deterministic. So I cannot confirm for 100% that the patch doesn't cause any regression. Though it rather seems it's not. See attached diff output between runs without and with the patch. > > Can we get the patch to upstream now? Please can send the version that you tested. You mentioned before that I had applied the fix to the wrong place. Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-06-08 13:47 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-28 15:29 Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list Petr Sumbera 2020-05-28 16:01 ` Rainer Orth 2020-06-01 12:47 ` Petr Sumbera 2020-06-01 11:39 ` Petr Sumbera 2020-06-01 19:12 ` Pedro Alves 2020-06-02 7:32 ` Petr Sumbera 2020-06-02 14:53 ` Pedro Alves 2020-06-02 16:30 ` Petr Sumbera 2020-06-02 17:14 ` Pedro Alves 2020-06-03 13:09 ` Petr Sumbera 2020-06-08 9:51 ` Petr Sumbera 2020-06-08 13:47 ` Pedro Alves
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).