Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I compile a program that coredumps. I'd like to debug it, but lo and behold the core dump has been moved from its origianl directory and then deleted. Version-Release number of selected component (if applicable): abrt-1.0.2-1.fc12.x86_64 How reproducible: Always. Steps to Reproduce: 1. Create a program with an intentional crash bug 2. Make sure abrtd is running 3. Run the program so it core dumps Actual results: The core dump is not there. Messages says the following: Jan 5 10:49:36 manic2 kernel: nav[24393]: segfault at 7ffb96789f47 ip 0000000000401a79 sp 00007fff5201e510 error 4 in nav[400000+8000] Jan 5 10:49:36 manic2 abrt: saved core dump of pid 24393 (/home/xyz/nav) to /var/cache/abrt/ccpp-1262706576-24393/coredump (6033408 bytes) Jan 5 10:49:37 manic2 abrtd: Executable doesn't belong to any package Jan 5 10:49:37 manic2 abrtd: Corrupted or bad crash, deleting Expected results: Leave my core dump alone if it does not correspond to any package. Additional info: Workaround is to stop abrtd. There ought to be a way to configure this behaviour, IMHO.
Bug 530637 notes a configuration option that should do this. However, for software not part of any package, it might be a good idea to simply make this the default behavior, since it's likely to be software under development. (And in any case, if the crash can't be reported, the forensic evidence should be left in place in the hopes of a manual report or diagnosis.) The configuration option is also not easy to find on the ABRT web site and manpages, but the same problem has been reported three times (here, Bug 530637, and Bug 541705), so it might be worthwhile to note it more prominently.
This option has been defaulted to yes and respects ulimit settings, so it shouldn't eat the coredumps anymore (since the next update).
Just to be clear: not only should the coredump not be deleted, it should *not* be moved from its original location either. Hopefully the changes address this issue as well.
*** This bug has been marked as a duplicate of bug 541705 ***