Bug 612472 - No core file while glibc reports core dumped
Summary: No core file while glibc reports core dumped
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: abrt (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
low
medium
Target Milestone: rc
: ---
Assignee: Denys Vlasenko
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-08 10:22 UTC by Xiaohong Wang
Modified: 2010-07-20 11:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-20 11:41:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Xiaohong Wang 2010-07-08 10:22:25 UTC
Description of problem:


Version-Release number of selected component (if applicable):
glibc-2.12-1.4.el6.x86_64

How reproducible:
always

Steps to Reproduce:
[root@nec-em18 test]# ulimit -f 102400
[root@nec-em18 test]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) 102400
pending signals                 (-i) 7862
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

[root@nec-em18 test]# fallocate -l $((102400*1024)) aaa
[root@nec-em18 test]# ll -h
total 100M
-rw-r--r--. 1 root root 100M Jul  8 06:07 aaa
[root@nec-em18 test]# fallocate -l $((102410*1024)) aaa
File size limit exceeded (core dumped)
[root@nec-em18 test]# ls
aaa
[root@nec-em18 test]# dmesg | tail
SELinux: initialized (dev loop0, type xfs), uses xattr
XFS mounting filesystem loop1
Ending clean XFS mount for filesystem: loop1
SELinux: initialized (dev loop1, type xfs), uses mountpoint labeling
XFS mounting filesystem loop0
Ending clean XFS mount for filesystem: loop0
SELinux: initialized (dev loop0, type xfs), uses xattr
XFS mounting filesystem loop0
Ending clean XFS mount for filesystem: loop0
SELinux: initialized (dev loop0, type xfs), uses xattr
[root@nec-em18 test]# ls
aaa
[root@nec-em18 test]# ulimit -c unlimited
[root@nec-em18 test]# fallocate -l $((102410*1024)) aaa
File size limit exceeded (core dumped)
[root@nec-em18 test]# ls
aaa  core.18841
[root@nec-em18 test]# strings /lib64/libc-2.12.so | grep 'File size limit'
File size limit exceeded
[root@nec-em18 test]# rpm -qf  /lib64/libc-2.12.so
glibc-2.12-1.4.el6.x86_64
[root@nec-em18 test]# uname -r
2.6.32-42.el6.x86_64
  
Actual results:


Expected results:


Additional info:

Comment 3 Denys Vlasenko 2010-07-14 10:27:23 UTC
(In reply to comment #0)
> Description of problem:
> 
> 
> Version-Release number of selected component (if applicable):
> glibc-2.12-1.4.el6.x86_64
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> [root@nec-em18 test]# ulimit -f 102400
> [root@nec-em18 test]# ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) 102400
> pending signals                 (-i) 7862
> max locked memory       (kbytes, -l) 64
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) 10240
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 1024
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> [root@nec-em18 test]# fallocate -l $((102400*1024)) aaa
> [root@nec-em18 test]# ll -h
> total 100M
> -rw-r--r--. 1 root root 100M Jul  8 06:07 aaa

> [root@nec-em18 test]# fallocate -l $((102410*1024)) aaa
> File size limit exceeded (core dumped)
> [root@nec-em18 test]# ls
> aaa

Is *this* the the problem - that you see "(core dumped)" but there is no core file, and the expected behavior is that there is no "(core dumped)" message?

> [root@nec-em18 test]# ulimit -c unlimited
> [root@nec-em18 test]# fallocate -l $((102410*1024)) aaa
> File size limit exceeded (core dumped)
> [root@nec-em18 test]# ls
> aaa  core.18841

Now you are getting both the message and the core, which is ok. Right?

The problem in the first case is that kernel _does_ dump core, but it dumps it to userspace helper, not to a plain file. Then helper notices that corefile exceeds the limit and does not save it.

It is debatable whether this change in behavior can be classified as bug. If we do want to retain old behavior, it needs to be done on kernel side (with a horrible hack to not report "core dumped" bit even though kernel does the dumping... kernel engineers will fight it tooth and nail)

Please let me know whether this is really necessary.

Comment 4 Denys Vlasenko 2010-07-20 11:41:20 UTC
Closing as "not a bug". If you desperately need compatible behaviour, reopen this bz and assign it to kernel.


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