Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: core files are no longer saved even despite application expects it. Version-Release number of selected component (if applicable): abrt-0.0.10-1.fc12.x86_64 How reproducible: Always. Steps to Reproduce: service abrtd start wget http://ftp.sh.cvut.cz/MIRRORS/gnu/pub/gnu/gdb/gdb-7.0.tar.bz2 tar xjf gdb-7.0.tar.bz2 cd gdb-7.0 ./configure make cd gdb/testsuite make site.exp runtest gdb.base/corefile.exp ulimit -c unlimited runtest gdb.base/corefile.exp Actual results: WARNING: can't generate a core file - core tests suppressed - check ulimit -c WARNING: can't generate a core file - core tests suppressed - check ulimit -c + abrt: saved core dump of pid 19280 to /var/cache/abrt/ccpp-1256332847-19280/coredump abrtd: Executable doesn't belong to any package abrtd: Corrupted or bad crash, deleting... Expected results: # of expected passes 13 # of expected passes 13 Additional info: gdb.base/corefile.exp already internally does `ulimit -c unlimited'. There are multiple possible resolutions with various pros/cons but the current state is not right. IMO: Always process the core file as you currently do. Save also the core file to its former disk location respecting original ulimit.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
There is an option in /etc/abrt/plugins/CCpp.conf: MakeCompatCore = no which (if enabled) makes ABRT to create the coredump in the cwd of the crashed program, the core file is then called core.<pid> I hope, this will fix this issue. Jirka
Note that it looks like kernel does not respect ulimit setting in this case (when there is a user-specified coredump handler): even if ulimit -c is 0, the handler is still called. Worse still, looks like handler has no way to know that ulimit -c was 0, so it cannot mimic correct behavior. IOW: with MakeCompatCore = yes, coredump will be created even if ulimit -c is 0, which is quite typical. That's why the default is "MakeCompatCore = no" and why "MakeCompatCore = yes" can't be recommended as typical setting. User needs to know what he is doing by setting it to "yes".
Thanks for the analysis. As I do not understand it more there should exist a Component=kernel Bug for it, shouldn't it? Either reassigned this one or a new one this will depend on.
Related bug: 541705
Thankfully, no. There is a %c specifier for this, yay! commit 74aadce986052f20088c2678f589ea0e8d3a4b59 Author: Neil Horman <nhorman> Date: Tue Oct 16 23:26:35 2007 -0700 ... diff --git a/fs/exec.c b/fs/exec.c index 86c4554..6450157 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -29,6 +29,7 @@ #include <linux/stat.h> #include <linux/fcntl.h> #include <linux/smp_lock.h> +#include <linux/string.h> #include <linux/init.h> #include <linux/pagemap.h> #include <linux/highmem.h> @@ -1514,6 +1515,14 @@ static int format_corename(char *corename, const char *pattern, long signr) goto out; out_ptr += rc; break; + /* core limit size */ + case 'c': + rc = snprintf(out_ptr, out_end - out_ptr, + "%lu", current->signal->rlim[RLIMIT_CORE].rlim_cur); + if (rc > out_end - out_ptr) + goto out; + out_ptr += rc; + break; I added %c usage to abrt git and run tested. Works!
Fixed in git.
abrt-1.0.6-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/abrt-1.0.6-1.fc12
abrt-1.0.6-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update abrt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1470
abrt-1.0.6-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.