Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Rainer Orth]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

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
> 

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Pedro Alves]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Pedro Alves]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Pedro Alves]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Petr Sumbera]

[-- 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

Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list

[Pedro Alves]

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