This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix 'gcore' with exited threads


On 06/09/2014 09:30 PM, Jan Kratochvil wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1099405
>
> Program received signal SIGABRT, Aborted.
> [...]
> (gdb) gcore foobar
> Couldn't get registers: No such process.
> (gdb) info threads
> [...]
> (gdb) gcore foobar
> Saved corefile foobar
> (gdb)
>
> gcore tries to access the exited thread:
> [Thread 0x7ffff7fce700 (LWP 6895) exited]
> ptrace(PTRACE_GETREGS, 6895, 0, 0x7fff18167dd0) = -1 ESRCH (No such process)

Note this will still happen if you have the exited thread selected,
as in that case the thread can't be deleted:

$ ./gdb ~/gdb/tests/threads -ex "set non-stop on"
...
(gdb) t 2
[Switching to thread 2 (Thread 0x7ffff7fc6700 (LWP 23009))]
#0  thread_function0 (arg=0x0) at threads.c:64
64              usleep (1);  /* Loop increment.  */
(gdb) p *myp=0
$1 = 0
(gdb) c&
Continuing.
(gdb) [Thread 0x7ffff7fc6700 (LWP 23009) exited]
(gdb) thread
[Current thread is 2 (Thread 0x7ffff7fc6700 (LWP 22973)) (exited)]
(gdb) info threads
  Id   Target Id         Frame
  3    Thread 0x7ffff77c5700 (LWP 22974) "threads" (running)
  1    Thread 0x7ffff7fc7740 (LWP 22972) "threads" (running)

The current thread <Thread ID 2> has terminated.  See `help thread'.
(gdb) gcore
Couldn't get registers: No such process.
(gdb)

It seems to me linux_corefile_thread_callback should skip exited
threads too.

> Without the TRY_CATCH protection testsuite FAILs for:
> 	FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile
> 	FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format)

What does the log show ?

> Maybe the TRY_CATCH could be more inside update_thread_list().

I'll assume "info threads" is failing at that point too
then.  Maybe we should downgrade whatever error is triggering
to a warning?

> Similar update_thread_list() call is IMO missing in procfs_make_note_section()
> but I do not have where to verify that change.

I wonder whether we should update the thread list in generic
code (write_gcore_file).

> +gdb_test_multiple "help gcore" "help gcore" {
> +    -re "Undefined command: .gcore.*\r\n$gdb_prompt $" {

Is this coming from copy/paste of existing tests?  I believe
this is is stale -- gcore.o has been in COMMON_OBS for a while
now.  I think the actual error will be whatever the default for
the target method throws.

> +	# gcore command not supported -- nothing to test here.
> +	unsupported "gdb does not support gcore on this target"
> +	return -1
> +    }
> +    -re "Save a core file .*\r\n$gdb_prompt $" {
> +	pass "help gcore"
> +    }
> +}

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]