Description of problem: abrt-hook-ccpp truncates coredump from my X server Version-Release number of selected component (if applicable): abrt-addon-ccpp-1.0.8-2.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1. crash X server 2. run abrt-gui as root 3. attempt to generate backtrace for X Actual results: Useful coredump for X server crash, allowing a bug to be reported Expected results: Cored file is truncated Additional info: I cannot use audacity without causing my X server to abort (Bug 577297) but when I try to get a backtrace from abrt it tells me the core file is truncated. This was crashing eu-unstrip (Bug 577310) The backtrace I get in abrt is warning: section .gnu.liblist not found in /usr/lib/debug/usr/bin/Xorg.debug warning: section .gnu.conflict not found in /usr/lib/debug/usr/bin/Xorg.debug "/var/cache/abrt/ccpp-1271029896-17921/coredump" is not a core dump: File truncated No shared libraries loaded at this time. No symbol "__abort_msg" in current context. No symbol "__glib_assert_msg" in current context.
I've just updated to these versions from the updates-testing repo: abrt-addon-ccpp-1.0.9-1.fc12.x86_64 xorg-x11-server-Xorg-1.7.6-3.fc12.x86_64 Now abrt doesn't even notice that X crashed
I got this X crash again, and abrt has the crash, but the core is still truncated /var/log/messages shows: May 12 15:39:51 moria abrt[16981]: saved core dump of pid 3848 (/usr/bin/Xorg) to /var/cache/abrt/ccpp-1273675191-3848.new/coredump (65416 bytes) May 12 15:39:51 moria abrtd: Directory 'ccpp-1273675191-3848' creation detected May 12 15:39:51 moria abrtd: New crash /var/cache/abrt/ccpp-1273675191-3848, processing May 12 15:39:51 moria abrtd: Registered Action plugin 'RunApp' May 12 15:39:51 moria abrtd: RunApp('/var/cache/abrt/ccpp-1273675191-3848','test x"`cat component`" = x"xorg-x11-server-Xorg" && cp /var/log/Xorg.0.log .') May 12 15:39:52 moria kdm[1626]: X server for display :1 terminated unexpectedly May 12 15:39:53 moria kernel: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id after I login to a new X session and run abrt-gui as root it shows: May 12 15:40:41 moria abrtd: Getting crash infos... May 12 15:40:41 moria abrtd: '/var/cache/abrt/ccpp-1271983160-27679' does not exist May 12 15:40:41 moria abrtd: Dump directory for crash_id 500:704e0dce48b5d0640e00c4892d9d90eb5cf8664b doesn't exist or misses crucial files, deleting May 12 15:41:22 moria abrtd: Creating report... May 12 15:41:22 moria abrtd: abrt-debuginfo-install exited with 2 I really want to debug Bug 577297 but I can't because of this problem with truncated core files. How do I turn off the abrt hook so that I get a corefile I can examine myself?
also, it seems significant that the corefile is truncated to 120 bytes less than 64k, the pipe buffer limit
I tried setting kernel.core_pattern to "/tmp/corefiles/core" (after creating the directory) and now when X crashes I get no core file.
The truncated corefile seems more like a kernel bug -> reassigning.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I don't get any core file now, so it's hard to know if the truncation bug is still present or not
I'm having problems with truncated core files from Xvnc on F14. Kernel 2.6.35.6-48.fc14.x86_64.
After a "yum remove abrt", core files are no longer truncated.
Peter, you may want to change release to F-14 before this F-12 bug is closed due to release EOL.
(In reply to comment #9) > After a "yum remove abrt", core files are no longer truncated. Can you reproduce this reliably? If so that would be awesome if you post it here, because this bug is really pita to investigate/fix...
(In reply to comment #10) > Peter, you may want to change release to F-14 before this F-12 bug is closed > due to release EOL. Standard problem: I am not authorized to change the version.
(In reply to comment #11) > (In reply to comment #9) > > After a "yum remove abrt", core files are no longer truncated. > > Can you reproduce this reliably? If so that would be awesome if you post it > here, because this bug is really pita to investigate/fix... Did a quick test, "yum install abrt". But now I could not reproduce the problem.
I can change the version if you confirm it definitely happens on F14 I don't see the bug anymore, due to something else changing, but I suspect it's still present and latent
It happened on my computer just yesterday, so I can confirm it myself...
I can confirm this on 2.6.32-71.24.1.el6.x86_64. I didn't get this for xserver though. Basically, if i change core_pattern to not use abrt, cores are fine. There seems to be a problem handling signals while the kernel is in the middle of a coredump. file->f_op->write(..) in dump_write(..) returns -ERESTARTSYS because it got a signal in the middle of a coredump. And oddly, this seems to happen only with abrt. Workaround is to change dump_write(..) to clear the SIG_PENDING flag when ERESTARTSYS is detected, and then trying to file->f_op->write(..) again solves the problem.
(In reply to comment #16) > I can confirm this on 2.6.32-71.24.1.el6.x86_64. I didn't get this for xserver > though. > > Basically, if i change core_pattern to not use abrt, cores are fine. There > seems to be a problem handling signals while the kernel is in the middle of a > coredump. file->f_op->write(..) in dump_write(..) returns -ERESTARTSYS because > it got a signal in the middle of a coredump. And oddly, this seems to happen > only with abrt. > > Workaround is to change dump_write(..) to clear the SIG_PENDING flag when > ERESTARTSYS is detected, and then trying to file->f_op->write(..) again solves > the problem. Thanks for the deep analysis! I guess it would happen with any customer coredumper hooked using the pipe in core_pattern?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still a problem with 3.9 based F19 kernels?
This bug just turned up for me on RHEL 6.4 (Santiago), 2.6.32-358.11.1.el6.x86_64. Test case: ulimit -c unlimited echo 'main() {abort();}' | gcc -xc - && eval './a.out; du core*' --> 0 core.9289 Reboot did not help. "yum remove abrt" fixed it, as Peter Åstrand suggested. /proc/sys/kernel/core_pattern contained "|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e" and says "core" after the yum command above.
I wrote: > This bug just turned up for me on RHEL 6.4 (Santiago), > 2.6.32-358.11.1.el6.x86_64. On my Dell laptop. Not on my Dell desktop, with the same OS release, kernel and core_pattern. Don't know what's different.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.