Unbreaking gdb on Solaris post-multitarget [PR 25939]

Rainer Orth
2020-06-16T14:21:47Z

[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]

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.

Here's what I see:

$ ./gdb -D ./data-directory ./hello
GNU gdb (GDB) 10.0.50.20200106-git
[...]
Reading symbols from ./hello...
(gdb) run
Starting program: /vol/obj/gnu/gdb/gdb/reghunt/no-resync/122448/gdb/hello
/vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:336: internal-error: thread_info::thread_info(inferior*, ptid_t): Assertion `inf_ != NULL' failed.

Here's the start of the corresponding stack trace:

#0 internal_error (
file=file@entry=0x966150 "/vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c", line=line@entry=336, fmt=0x9ddb94 "%s: Assertion `%s' failed.")
at /vol/src/gnu/gdb/hg/master/reghunt/gdb/gdbsupport/errors.c:51
#1 0x0000000000ef81f4 in thread_info::thread_info (this=0x1212020,
inf_=<optimized out>, ptid_=...)
at /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:344
#2 0x0000000000ef82cd in new_thread (inf=inf@entry=0x0, ptid=...)
at /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:239
#3 0x0000000000efac3c in add_thread_silent (
targ=targ@entry=0x11b0940 <the_procfs_target>, ptid=...)
at /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:304
#4 0x0000000000d90692 in procfs_target::create_inferior (
this=0x11b0940 <the_procfs_target>,
exec_file=0x13dbef0 "/vol/obj/gnu/gdb/gdb/reghunt/no-resync/122448/gdb/hello", allargs="", env=0x13c48f0, from_tty=<optimized out>)
at /vol/src/gnu/gdb/hg/master/reghunt/gdb/gdbsupport/ptid.h:47
#5 0x0000000000c84e64 in run_command_1 (args=<optimized out>, from_tty=1,
run_how=run_how@entry=RUN_NORMAL)
at /vol/gcc-9/include/c++/9.1.0/bits/basic_string.h:263
#6 0x0000000000c85007 in run_command (args=<optimized out>,
from_tty=<optimized out>)
at /vol/src/gnu/gdb/hg/master/reghunt/gdb/infcmd.c:687

Looking closer, I found that in add_thread_silent as called from
procfs.c (procfs_target::create_inferior) find_inferior_ptid returns
NULL. The all_inferiors (targ) iterator comes up empty.

Going from there, I see that in add_thread_silent

m_target_stack = {m_top = file_stratum, m_stack = {0x20190e0 <the_dummy_target>, 0x200b8c0 <exec_ops>, 0x0, 0x0, 0x0, 0x0, 0x0}}}

i.e. the_procfs_target is missing compared to the_amd64_linux_nat_target
on Linux/x86_64.

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: reghunt.patch --]
[-- Type: text/x-patch, Size: 354 bytes --]

diff --git a/gdb/procfs.c b/gdb/procfs.c
--- a/gdb/procfs.c
+++ b/gdb/procfs.c
@@ -3086,6 +3090,9 @@ procfs_target::create_inferior (const ch
shell_file = tryname;
}

+ if (!target_is_pushed (this))
+ push_target (this);
+
pid = fork_inferior (exec_file, allargs, env, procfs_set_exec_trap,
NULL, NULL, shell_file, NULL);

[-- Attachment #3: Type: text/plain, Size: 1316 bytes --]

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, 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.

So I'd very much appreciate any suggestions and help to make gdb work
again on Solaris.

Thanks.
Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University