Bug 552606

Summary:	abrt eats my coredump so i can't debug my software
Product:	[Fedora] Fedora	Reporter:	A.Russo <russo.lutions>
Component:	abrt	Assignee:	Jiri Moskovcak <jmoskovc>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	anton, beland, dfediuck, dvlasenk, iprikryl, jmoskovc, kklic, mnowak, npajkovs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-02 13:56:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description A.Russo 2010-01-05 16:37:38 UTC

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.

Comment 1 Christopher Beland 2010-01-13 17:48:37 UTC

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.

Comment 2 Jiri Moskovcak 2010-01-13 18:15:52 UTC

This option has been defaulted to yes and respects ulimit settings, so it shouldn't eat the coredumps anymore (since the next update).

Comment 3 A.Russo 2010-01-13 18:42:39 UTC

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.

Comment 4 Jiri Moskovcak 2010-02-02 13:56:29 UTC


*** This bug has been marked as a duplicate of bug 541705 ***