Re: [PATCH] gdb/gcore: interrupt all threads before generating the corefile

[John Baldwin <jhb@FreeBSD.org>]

On 10/6/22 2:50 AM, Lancelot SIX via Gdb-patches wrote:
> In non-stop mode, if the user tries to generate a core dump (using the
> gcore command) while some threads are running, a non-helpful error
> message is shown.
> 
> Lets consider the following session as an example (debugging the test
> program included in this patch):
> 
>      (gdb) set non-stop on
>      (gdb) b 37
>      (gdb) r
>      Thread 1 "gcore-nonstop" hit Breakpoint 1, main () at gcore-nonstop.c:39
>      (gdb) info thread
>         Id   Target Id                                          Frame
>       * 1    Thread 0x7ffff7d7a740 (LWP 431838) "gcore-nonstop" main () * at gcore-nonstop.c:39
>         2    Thread 0x7ffff7d79640 (LWP 431841) "gcore-nonstop" (running)
>      (gdb) gcore
>      Couldn't get registers: No such process.
> 
> The reported error ("No such process") does not help the user understand
> what happens.  This is due to the fact that we cannot access the
> registers of a running thread.  Even if we ignore this error, generating
> a core dump while any thread might update memory would most likely
> result in a core file with an inconsistent view of the process' memory.
> 
> To solve this, this patch proposes to change the gcore command so it
> first stops all running threads before generating the corefile, and then
> resumes them in their previous state.
> 
> The patch proposes to stop all threads across all the inferiors (not
> just the current one) just in case the memory space is shared between
> inferiors.
I agree with the idea in concept (gcore should stop all threads so it can
write out a consistent snapshot).

-- 
John Baldwin