Re: Unbreaking gdb on Solaris post-multitarget [PR 25939]

[Pedro Alves <palves@redhat.com>]

On 6/16/20 3:21 PM, Rainer Orth wrote:
> Some time ago, when testing gdb master on Solaris again after several
> months, I discovered that gdb couldn't execute even a trivial program
> anymore.  This had gone unnoticed by the Solaris buildbots since the
> code continued to compile just fine.  Those bots are build-only since
> many tests (especially thread tests) are either flaky or time out.
> 
> A reghunt identified the multi-target merge as the culprit.

I'm sorry about that.

> I've managed to get a bit further with the following patch which is
> intended to push the procfs target first:

That patch looks good to me.

> 
> 
> However, while I now get over the initial assertion failure, I run
> instead into
> 
> procfs: couldn't find pid 0 in procinfo list.
> procfs: init_inferior, open_proc_files line 2878, /proc/6031: No such file or directory.
> 
> When I break in procfs.c (procfs_init_inferior), I can see that
> create_procinfo succeeds.  However, looking at the process tree at this
> point, I see that the debuggee is still marked as defunct
> 
>                   18377 /vol/gcc/bin/gdb -i=mi /vol/gnu/obj/gdb/gdb/reghunt/no-r
>                     18379 /vol/gnu/obj/gdb/gdb/reghunt/no-resync/122457/gdb/gdb 
>                       18382 <defunct>
> 
> so open_procinfo_files fails because /proc/<pid> only contains psinfo
> and usage, but no ctl file yet.
> 
> I tried to do the same with a version of gdb from immediately before the
> multi-target merge: while that can run a test program interactively just
> fine, 

It's not clear to me whether you're saying that a version from before
the multi-target changes can run a test program fine due to not needing
the push_target fix, or whether the multi-target patchset itself caused
this second issue you're observing even when debugging a simple hello
program.

running that gdb under gdb itself most often leads to the same
> error.  This very much seems like a race condition to me, but at the
> moment I'm pretty much at a loss how to investigate this further.

Could this be a race somehow more exposed now due to GDB now spawning worker
threads?  What happens if you debug a GDB that doesn't spawn worker
threads?  Like:

./gdb -D ./data-directory --args ./gdb -ex "maint set worker-threads 0"

Does that problem trigger as often that way?

Or, what happens if you use master GDB with your push_target fix
to debug an older GDB?

Thanks,
Pedro Alves