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

Pedro Alves
2020-06-16T19:16:43Z

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