On 05/13/2016 01:05 AM, Michael Catanzaro wrote:
On Thu, 2016-05-12 at 23:26 +0100, Peter Robinson wrote:
Yet further up in the thread there are people saying that it's not
suitable for outside of developers.
It's not suitable for non-developers in the sense that no command line
program is ever suitable for nontechnical users, but it's not somehow
inappropriate to have enabled on all systems. It's a tool that makes
debugging and bug reporting easier, but it's not a distro bug reporting
tool. ABRT remains our distro bug reporting tool.
Basically: if you want to work with core dumps, you probably want to
use coredumpctl (though understandably the ABRT folks prefer abrt-cli).
If not, you don't care. Status quo is that we have coredumpctl
installed and broken by default.
Michael
Well, if I need to analyze core dump files during development I prefer
no intermediate tool - no ABRT, no systemd-coredump. I just set 'ulimit
-c unlimited' and run gdb on the file generated in CWD. Actually, that's
not true, I run my programs in gdb, so I don't need to analyze local
core dump files most of the time. I usually need to analyze core dump
files generated on foreign systems.
One benefit of ABRT for some developers was that it could create the old
way core dump files in CWD but starting with systemd-229 we had to
disable this feature by default. Because systemd changed the default
RLIMIT_CORE from 0 to unlimited ('ulimit -c').
I do prefer abrt-cli (or abrt - which can run gdb too) when I need to
work with errors/crashes/problems of any source - Python, Java, C/C++,
Kernel oops, Ruby, etc. I can analyze them and eventually report them.
systedm-coredump makes ABRT's job harder. Currently, ABRT fails to get
core dump files from systemd-journal because systemd-coredump switched
from xz compression to lz4 compression. My bad, I should have been
watching systemd development.
Best regards,
Jakub
ABRT folk
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
