public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump
Date: Mon, 18 Sep 2017 18:44:00 -0000	[thread overview]
Message-ID: <1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com> (raw)
In-Reply-To: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com>

So far the test suite skips tests if they need system-generated core files
and the core files can not be found.  In particular this is usually the
case on systems with an active systemd-coredump service.  On such systems,
core files are not written into the local directory, but made accessible
via a command-line utitily "coredumpctl" instead.

This patch enables processing core files on such systems as well.  Note
that there are a few quirks:

* In my tests, after invoking a command that dumps core, it could happen
  that "coredumpctl" did not find the dump immediately afterwards.  After
  waiting a bit, the dump was found and could be accessed.  Thus the patch
  performs a single wait-and-retry in case of failure.

* There does not seem to be a way for a user to remove specific core dumps
  from the journal.  Thus it can happen that "coredumpctl" returns an old
  dump, and the test case continues with that instead of the new one.  It
  might be possible to improve the logic here, by considering the time
  stamps as well.  I leave that for a future patch.

* On the system I've tested it on, the bigcore.exp test case still failed
  because coredumpctl truncated the core file after 4G for some reason.

gdb/testsuite/ChangeLog:

	* lib/gdb.exp (find_core): Add handling for targets with
	systemd-coredump, using the coredumpctl command.
---
 gdb/testsuite/lib/gdb.exp | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 1fd0009..7f80e12 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5877,6 +5877,19 @@ proc find_core {binfile coredir {destcore ""}} {
 	}
     }
 
+    # We may be running on a system with the systemd-coredump service in
+    # effect; try the coredumpctl command.  But due to asynchronous
+    # processing the core dump may not have been processed yet.  Thus wait
+    # a bit and retry after failure.
+    foreach delay {0 1} {
+	sleep $delay
+	if {![catch {exec -ignorestderr coredumpctl -o $destcore dump $binfile}]} {
+	    if [file exists $destcore] {
+		return $destcore
+	    }
+	}
+    }
+
     warning "Can not locate core dump generated by \"[file tail $binfile]\"."
     return ""
 }
-- 
2.9.4

  parent reply	other threads:[~2017-09-18 18:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-18 18:42 [PATCH 0/2] GDB test suite: Support " Andreas Arnez
2017-09-18 18:43 ` [PATCH 1/2] GDB test suite: Add helper for locating core files Andreas Arnez
2017-10-07 16:45   ` Kevin Buettner
2017-10-09 18:46     ` Andreas Arnez
2017-10-11  8:17       ` Kevin Buettner
2017-10-11 14:53         ` Andreas Arnez
2017-10-12 13:47       ` Pedro Alves
2017-10-12 16:48         ` Pedro Alves
2017-10-17  9:22           ` Pedro Alves
2017-10-12 17:00         ` Andreas Arnez
2017-10-13  9:28           ` Maciej W. Rozycki
2017-10-13 10:56             ` Andreas Arnez
2017-10-17 13:58               ` Maciej W. Rozycki
2017-10-17 10:06           ` Pedro Alves
2017-10-17 10:01       ` Pedro Alves
2017-10-17 18:21         ` Maciej W. Rozycki
2017-10-18 11:46           ` Pedro Alves
2017-09-18 18:44 ` Andreas Arnez [this message]
2017-10-17 10:22   ` [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump Pedro Alves
2017-10-17 17:37     ` Andreas Arnez
2017-10-17 18:09       ` Pedro Alves
2017-10-17 18:14         ` Pedro Alves
2017-10-17 18:17           ` Pedro Alves
2017-10-18 15:56         ` Andreas Arnez
2017-10-19 10:48           ` Pedro Alves
2017-10-23 13:41             ` Andreas Arnez
2017-10-23 14:30               ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com \
    --to=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).