Bug 768149 - System doesn't generate corefile when expected
Summary: System doesn't generate corefile when expected
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 16
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-15 21:26 UTC by Scott Lurndal
Modified: 2015-02-01 22:55 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Move to abrt Why is this software deleting my core file? I've removed the package. but it shouldn't be installed by default. Dec 15 13:16:52 wot kernel: [16096.132000] test[9739]: segfault at 0 ip 00000000004005da sp 00007fff812987e0 error 6 in test[400000+1000] Dec 15 13:16:52 wot abrtd: Directory 'ccpp-2011-12-15-13:16:52-9739' creation detected Dec 15 13:16:52 wot abrt[9740]: Saved core dump of pid 9739 (/tmp/test) to /var/spool/abrt/ccpp-2011-12-15-13:16:52-9739 (397312 bytes) Dec 15 13:16:54 wot abrtd: Executable '/tmp/test' doesn't belong to any package Dec 15 13:16:54 wot abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2011-12-15-13:16:52-9739 (res:2), deleting
Clone Of:
Environment:
Last Closed: 2012-08-30 00:57:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Scott Lurndal 2011-12-15 21:26:34 UTC
Description of problem:
  This may be a kernel issue.

  When a fatal signal occurs during static constructor initialization in the C++ runtime, a core file will not be produced (although the shell message indicates that the exit status includes the 'core dumped' bit).   The exit status records 'core dumped' regardless of the value of the core file resource limit, and no core file is generated regardless of the value of the core file resource limit.

Version-Release number of selected component (if applicable):

  FC16 + updates as of 2011-12-14

How reproducible:

  Can be reproduced at will

Steps to Reproduce:

1) Start with the following test program:

$ cat test.cpp
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

class c_mp {

public:
      c_mp(void);
};

c_mp    mp;


c_mp::c_mp(void)
{
    char *cp = (char *)0;

    fprintf(stderr, "constructor\n");
    
    *cp = 1;
}

int
main(int argc, char **argv, char **envp)
{

     exit(EXIT_SUCCESS);
}

Actual results:

With ulimit -c 0:
$ ulimit -a          
address space limit (kbytes)   (-M)  unlimited
core file size (blocks)        (-c)  0
cpu time (seconds)             (-t)  unlimited
data size (kbytes)             (-d)  unlimited
file size (blocks)             (-f)  unlimited
locks                          (-x)  unlimited
locked address space (kbytes)  (-l)  64
message queue size (kbytes)    (-q)  800
nice                           (-e)  0
nofile                         (-n)  1024
nproc                          (-u)  1024
pipe buffer size (bytes)       (-p)  4096
max memory size (kbytes)       (-m)  unlimited
rtprio                         (-r)  0
socket buffer size (bytes)     (-b)  4096
sigpend                        (-i)  7803
stack size (kbytes)            (-s)  8192
swap size (kbytes)             (-w)  not supported
threads                        (-T)  not supported
process size (kbytes)          (-v)  unlimited
$ g++ -o test test.cpp
$ ./test
constructor
Memory fault(coredump)
$ ls
at-spi2                                test
gnome-system-monitor.scott.1361976495  test.cpp
keyring-cggefY                         tracker-scott
pulse-2rPSCUzZUiWs                     yum_save_tx-2011-12-14-21-0235Ja_r.yumtx
pulse-PKdhtXMmr18n                     yum_save_tx-2011-12-14-21-05Z5F86K.yumtx
pulse-cXyHZzsRwpC5                     yum_save_tx-2011-12-14-21-05lG8lUs.yumtx
$ ulimit -c unlimited 
$ ulimit -a
address space limit (kbytes)   (-M)  unlimited
core file size (blocks)        (-c)  unlimited
cpu time (seconds)             (-t)  unlimited
data size (kbytes)             (-d)  unlimited
file size (blocks)             (-f)  unlimited
locks                          (-x)  unlimited
locked address space (kbytes)  (-l)  64
message queue size (kbytes)    (-q)  800
nice                           (-e)  0
nofile                         (-n)  1024
nproc                          (-u)  1024
pipe buffer size (bytes)       (-p)  4096
max memory size (kbytes)       (-m)  unlimited
rtprio                         (-r)  0
socket buffer size (bytes)     (-b)  4096
sigpend                        (-i)  7803
stack size (kbytes)            (-s)  8192
swap size (kbytes)             (-w)  not supported
threads                        (-T)  not supported
process size (kbytes)          (-v)  unlimited
$ ./test
constructor
Memory fault(coredump)
$ ls
at-spi2                                test
gnome-system-monitor.scott.13613234495 test.cpp
keyring-cXXXXY                         tracker-scott
pulse-2rPSCWEWERRWs                     yum_save_tx-2011-12-14-21-0234Ja_r.yumtx
pulse-PKdweaasdr18n                     yum_save_tx-2011-12-14-21-05Z5586K.yumtx
pulse-cXasdffffwpC5                     yum_save_tx-2011-12-14-21-05qQ8lUs.yumtx
$ gdb ./test
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/test...(no debugging symbols found)...done.
(gdb) r
Starting program: /tmp/test 
constructor

Program received signal SIGSEGV, Segmentation fault.
0x00000000004005da in c_mp::c_mp() ()
(gdb) bt
#0  0x00000000004005da in c_mp::c_mp() ()
#1  0x0000000000400623 in __static_initialization_and_destruction_0(int, int)
    ()
#2  0x0000000000400638 in _GLOBAL__sub_I_mp ()
#3  0x000000000040069d in __libc_csu_init ()
#4  0x00007ffff77c2630 in __libc_start_main (main=0x4005df <main>, argc=1, 
    ubp_av=0x7fffffffe958, init=0x400640 <__libc_csu_init>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe948)
    at libc-start.c:185
#5  0x00000000004004e9 in _start ()

Expected results:

Expected a core file in the current working directory.

Additional info:

Comment 1 Scott Lurndal 2011-12-15 21:39:53 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Move to abrt

Why is this software deleting my core file?

I've removed the package. but it shouldn't be installed by default.

Dec 15 13:16:52 wot kernel: [16096.132000] test[9739]: segfault at 0 ip 00000000004005da sp 00007fff812987e0 error 6 in test[400000+1000]
Dec 15 13:16:52 wot abrtd: Directory 'ccpp-2011-12-15-13:16:52-9739' creation detected
Dec 15 13:16:52 wot abrt[9740]: Saved core dump of pid 9739 (/tmp/test) to /var/spool/abrt/ccpp-2011-12-15-13:16:52-9739 (397312 bytes)
Dec 15 13:16:54 wot abrtd: Executable '/tmp/test' doesn't belong to any package
Dec 15 13:16:54 wot abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2011-12-15-13:16:52-9739 (res:2), deleting

Comment 2 Jiri Moskovcak 2011-12-16 09:29:49 UTC
What's the output of $ ulimit -c on your system? If you set ulimit -c unlimited (or some other sane limit) abrt will create core.<PID>.

Comment 3 Jiri Moskovcak 2011-12-16 09:34:54 UTC
Your test case from c#1 is wrong, you never get a core when running program in gdb. If you set ulimit -c unlimited and run your ./test you should get a core in CWD as you're are used to. If not then it's a bug in ABRT, but I just tried that and it works on my system.

Comment 4 Jiri Moskovcak 2011-12-16 09:40:21 UTC
Ah, sorry, I was a bit harsh and didn't noticed that you actually run the test after you set the ulimit. Meanwhile instead of removing you can just $ service abrt-ccpp stop which will restore the default corefile handling.

Comment 5 Jiri Moskovcak 2011-12-16 09:48:30 UTC
Did a quick test with you testing code:

[10:41:23 jmoskovc@dhcp-24-187 ~]$ ./a.out 
constructor
Segmentation fault (core dumped)
[10:42:03 jmoskovc@dhcp-24-187 ~]$ ls | grep core
core.4020


syslog:
Dec 16 10:42:03 dhcp-24-187 kernel: [ 2589.862142] a.out[4020]: segfault at 0 ip 00000000004005da sp 00007fff1522f530 error 6 in a.out[400000+1000]
Dec 16 10:42:03 dhcp-24-187 abrtd: Directory 'ccpp-2011-12-16-10:42:03-4020' creation detected
Dec 16 10:42:03 dhcp-24-187 abrt[4021]: Saved core dump of pid 4020 (/home/jmoskovc/a.out) to /var/spool/abrt/ccpp-2011-12-16-10:42:03-4020 (397312 bytes)
Dec 16 10:42:03 dhcp-24-187 abrtd: Executable '/home/jmoskovc/a.out' doesn't belong to any package
Dec 16 10:42:03 dhcp-24-187 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2011-12-16-10:42:03-4020' exited with 1
Dec 16 10:42:03 dhcp-24-187 abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2011-12-16-10:42:03-4020, deleting

- please note that abrt only removes the coredump copy in /var/spool/abrt, it doesn't remove the core in CWD
- ABRT had a few bugs in the logic which creates the cores in CWD which should be fixed by abrt-2.0.7 which is a pending update https://admin.fedoraproject.org/updates/FEDORA-2011-16990, could you please re-try it and let us know if it fixes your problem?

Comment 6 Scott Lurndal 2011-12-19 22:34:35 UTC
I'll try the new one when it pushes through updates.

I was quite surprised by the default core file behavior changing in such a way without any warning (that I could find) in the release notes.   Granted I upgraded from FC6 directly to FC16, but I think warnings to developers that your core file may not appear should be provided in the release notes(and that the wait status provided by the kernel to waitpid(2)/wait(2) is incorrect - i.e. the core file bit is set, even when no core file is emitted).

I question why abrt even cares about my executables - shouldn't they have been ignored (even if it is called 'test', which matches a system utility, the directory which contained the executable was /tmp, and the faulting process cwd was also /tmp).

When porting my application from FC6/Ubuntu 9.04 to FC16 to test the 4.6 version of gcc, the application immediately segfaulted, but I couldn't get a core dump.  It took a while for me to consider checking /var/log/messages for any indications as to why the core file was not being produced regardless of RLIM_CORE soft limit.
(Turned out to be an issue with the call order of static constructors being different between binutils/gcc 4.4 and binutils/gcc 4.6 - an easy fix once debugged).

I believe strongly that abrt should completely ignore any faulting executable that is not listed in the rpm database for the system (i.e. resolvable via rpm -q -f path); the core file behavior should be that of traditional unix (augmented with the pid when configured) and RHEL3/4/5 releases.

Comment 7 Jiri Moskovcak 2011-12-21 13:38:36 UTC
I'm not going to explain how abrt works, it's on our wiki, but when the abrt-ccpp service is enabled it can't ignore your cores, becuase it replaces the default core writing mechanism. The fact that it was "eating" your cores is unfortunate, but it wasn't our intention, it was a bug.

Comment 8 Fedora Update System 2012-08-10 07:56:37 UTC
libreport-2.0.12-2.fc17, abrt-2.0.11-1.fc17, btparser-0.18-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.11-1.fc17,libreport-2.0.12-2.fc17,btparser-0.18-2.fc17

Comment 9 Fedora Update System 2012-08-23 23:28:47 UTC
Package abrt-2.0.12-1.fc17, libreport-2.0.13-1.fc17, btparser-0.18-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.12-1.fc17 libreport-2.0.13-1.fc17 btparser-0.18-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.12-1.fc17,libreport-2.0.13-1.fc17,btparser-0.18-2.fc17
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2012-08-30 00:57:39 UTC
abrt-2.0.12-1.fc17, libreport-2.0.13-2.fc17, btparser-0.18-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Ravindra Maurya 2013-02-26 17:17:12 UTC
Trying to use LiveCode IDE, hit some issue, expecting core dump, /var/log/messages shows the following.

Feb 26 22:40:18 honeypot abrtd: Directory 'ccpp-2013-02-26-22:40:17-17832' creation detected
Feb 26 22:40:18 honeypot abrt[17839]: Saved core dump of pid 17832 (/home/rmaurya/.runrev/components/livecode-5.5.3-gm-2/livecode.x86) to /var/spool/abrt/ccpp-2013-02-26-22:40:17-17832 (38223872 bytes)
Feb 26 22:40:18 honeypot abrtd: Executable '/home/rmaurya/.runrev/components/livecode-5.5.3-gm-2/livecode.x86' doesn't belong to any package
Feb 26 22:40:18 honeypot abrtd: 'post-create' on '/var/spool/abrt/ccpp-2013-02-26-22:40:17-17832' exited with 1
Feb 26 22:40:18 honeypot abrtd: Corrupted or bad directory '/var/spool/abrt/ccpp-2013-02-26-22:40:17-17832', deleting


I'm on FC18
[rmaurya@honeypot ~]$ uname -a
Linux honeypot 3.7.8-202.fc18.x86_64 #1 SMP Fri Feb 15 17:33:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

To reproduce:-
- Install LiveCodeInstaller-5_5_3-Linux.x86 from runrev.com, use trial version.
- Create a main-stack, add button to frame, click code from the toolbar.
- IDE Crashes.

Any suggestions?


Note You need to log in before you can comment on or make changes to this bug.