Often I have found multiple systemd-coredump running, occupying huge memory. I presume that systemd-coredump is meant for handling the dumps of crashed processes, but why does it need to keep them persistently in memory. They have to be manually killed (I allowed them to stay in memory for quite some time to be sure of this).
Other users are also facing the same issue as mentioned in https://bbs.archlinux.org/viewtopic.php?pid=1247900
For now I have disabled the coredump. If required I could post the steps to reproduce the error (however I feel crashing a process should be sufficient)
Please clarify if this is a config issue or is something wrong at our end.
Should I expect some response?
I'm having this issue as well. My computer starts swapping heavily when this happens, often necessitating a hard reboot.
It's not with Chromium for me though, as described in that Archlinux discussion. It seems to be wine+µTorrent for me. µTorrent has a tendency to crash here, so I guess it just triggers the coredump.
All systemd-coredump instances exit correctly on their own when the dumps have been written to journal.
Not really a bug?
(In reply to comment #1)
> Should I expect some response?
When someone gets around to handling a bug, or they need some info, or have any useful input at all, then yes. Otherwise, no.
(In reply to comment #3)
> All systemd-coredump instances exit correctly on their own when the dumps
> have been written to journal.
> Not really a bug?
It's not a bug, things were working as designed. The problem was that writing big entries to the journal was a bit slow.
As of http://cgit.freedesktop.org/systemd/systemd/commit/?id=34c10968, coredumps are written to a file on disk. This should be both faster and require less memory.