darwin: Do not add a dummy thread
Starting a process on macOS/Darwin currently leads to this error:
/Users/simark/src/binutils-gdb/gdb/darwin-nat.c:383: internal-error: void darwin_check_new_threads(struct inferior *): Assertion `tp' failed.
with the corresponding partial backtrace (sorry, taken with lldb,
because well, gdb is broken :)):
frame #9: 0x000000010004605a gdb`darwin_check_new_threads(inf=0x0000000100edf670) at darwin-nat.c:383
frame #10: 0x0000000100045848 gdb`darwin_init_thread_list(inf=0x0000000100edf670) at darwin-nat.c:1710
frame #11: 0x00000001000452f8 gdb`darwin_ptrace_him(pid=8375) at darwin-nat.c:1792
frame #12: 0x0000000100041d95 gdb`fork_inferior(...) at fork-inferior.c:440
frame #13: 0x0000000100043f82 gdb`darwin_create_inferior(...) at darwin-nat.c:1841
frame #14: 0x000000010034ac32 gdb`run_command_1(args=0x0000000000000000, from_tty=1, tbreak_at_main=1) at infcmd.c:611
The issue was introduced by commit
"Share fork_inferior et al with gdbserver"
because it changed the place where the dummy thread (pid, 0, 0) is added,
relative to the call to the init_trace_fun callback. In this callback, darwin
checks for new threads in the program (there should be exactly one) in order to
update this dummy thread with the right tid. Previously, things happened in
this order:
- fork_inferior calls fork()
- fork_inferior adds dummy thread
- fork_inferior calls init_trace_fun callback, which updates the dummy
thread info
Following the commit mentioned above, the new thread is added in the
darwin-nat code, after having called fork_inferior (in
darwin_create_inferior). So gdb tries to do things in this order:
- fork_inferior calls fork()
- fork_inferior calls init_trace_fun callback, which tries to update
the dummy thread info
- darwin_create_inferior adds the dummy thread
The error happens while trying to update the dummy thread that has not
been added yet.
I don't think this dummy thread is necessary for darwin. Previously, it
was fork_inferior that was adding this thread, for all targets, so
darwin had to deal with it. Now that it's done by targets themselves,
we can just skip that on darwin. darwin_check_new_threads called
indirectly by init_trace_fun/darwin_ptrace_him will simply notice the
new thread and add it with the right information.
My level of testing was: try to start a process and try to attach to a
process, and it seems to work somewhat like it did before. I tried to
run the testsuite, but it leaves a huge amount of zombie processes that
launchd doesn't seem to reap, leading to exhaustion of system resources
(number of processes).
gdb/ChangeLog:
* darwin-nat.c (darwin_check_new_threads): Don't handle dummy
thread.
(darwin_init_thread_list): Don't update dummy thread.
(darwin_create_inferior, darwin_attach): Don't add a dummy thread.