Bug 612472
| Summary: | No core file while glibc reports core dumped | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Xiaohong Wang <xwang> |
| Component: | abrt | Assignee: | Denys Vlasenko <dvlasenk> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | dvlasenk, gavin, kklic, npajkovs, ovasik |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Xiaohong Wang
2010-07-08 10:22:25 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. Closing as "not a bug". If you desperately need compatible behaviour, reopen this bz and assign it to kernel. |