On Mon, 23 Jun 2014 17:06:37 +0200, Pedro Alves wrote:
> 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:

Confirmed, testcase extended.


> It seems to me linux_corefile_thread_callback should skip exited
> threads too.

Done.


> > 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 ?

gcore .../gdb/testsuite/gdb.threads/gcore-thread0.test^M
Cannot find new threads: debugger service failed^M
(gdb) FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile
+
core .../gdb/testsuite/gdb.threads/gcore-thread0.test^M
".../gdb/testsuite/gdb.threads/gcore-thread0.test" is not a core dump: File format not recognized^M
(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format)


> > 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?

It has other disadvantages.  Warning may get lost in some other messages and
user may miss some thread(s) during a falsely successfully finished command.


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

This is one of the general problems of GDB that one cannot do any change
affecting platforms which one cannot (or at least not easily enough) test on.

Platform not automatically being tested by Jenkins for any patch submitted to
Gerrit should be officially unsupported.


> > +gdb_test_multiple "help gcore" "help gcore" {
> > +    -re "Undefined command: .gcore.*\r\n$gdb_prompt $" {
> 
> Is this coming from copy/paste of existing tests?

Yes.


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

Likewise two paragraphs above.  Not sure what I should do with it:
 * If I remove the test from this my testcase and someone later fixes
   the 6 existing instances of this test this only test will remain unfixed.
 * If I waste the time reading the sources what should be the expected output
   I risk the test will not work anyway as I read it wrongly.
   And I will probably wrongly modify 6 other testsuite cases.
 * I can try to find a platform without gcore but in most cases in the past my
   attempts to build GDB on any non-Linux platforms failed.

I find this problem generally out of the scope of this mail thread / patch.


> > +	# 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"
> > +    }
> > +}


No regressions on {x86_64,x86_64-m32,i686}-fedora21pre-linux-gnu.


Thanks,
Jan