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 2/2] GDB test suite: Get core files on targets with systemd-coredump


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


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