public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Andreas Arnez <arnez@linux.vnet.ibm.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump
Date: Tue, 17 Oct 2017 10:22:00 -0000	[thread overview]
Message-ID: <38b0202f-5c78-a8bb-7bc8-e86f3a02ca33@redhat.com> (raw)
In-Reply-To: <1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com>

On 09/18/2017 07:41 PM, Andreas Arnez wrote:
> 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.

I'm a bit unsure about whether this is the right approach,
expecially given the caveats above.  Also, this seems to mean that
running the testsuite on such a system clutters the system log on and on,
maybe even triggers dispatch of notifications to admins, etc.

I wonder whether there's a way to tell systemd-coredump to
let the core dumps be generated on the file system for the current
shell environment?  Like we try to run "ulimit -c unlimited".

Failing that, it may be better to instead make the testsuite skip
the tests gracefully, and display a big and visible warning
if systemd-coredump is detected as active.

I mean, you already have to tweak other things in the system in
order to be able to run the testsuite correctly.  For example,
you have to tweak /proc/sys/kernel/yama/ptrace_scope to make
attach tests work at all, for example.  systemd-coredump kind of
seems like more of the same.

Dunno, as I said, I'm unsure.

Thanks,
Pedro Alves

  reply	other threads:[~2017-10-17 10:22 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 ` [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump Andreas Arnez
2017-10-17 10:22   ` Pedro Alves [this message]
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=38b0202f-5c78-a8bb-7bc8-e86f3a02ca33@redhat.com \
    --to=palves@redhat.com \
    --cc=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).