Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: When reporting many bugs with ABRT, I get something similar to: Generating core_backtrace Lock file './.lock' is locked by process 6567 Generating backtrace Backtrace is too big (33564131 bytes), reducing depth to 512 Backtrace is too big (33564131 bytes), reducing depth to 256 Backtrace is too big (33564131 bytes), reducing depth to 128 etc. The backtrace never decreases in size and I am unable to submit the bug. On a Core-i7, it is very slow and can easily take 30+ minutes to run through the gamut before giving up. Many people would not have the patience, so I suspect bug reports are not being reported when they otherwise should. Version-Release number of selected component (if applicable): gnome-abrt-0.3.0-3.fc19.x86_64 abrt-gui-2.1.6-3.fc19.x86_64 abrt-addon-vmcore-2.1.6-3.fc19.x86_64 abrt-libs-2.1.6-3.fc19.x86_64 abrt-addon-kerneloops-2.1.6-3.fc19.x86_64 abrt-addon-uefioops-2.1.6-3.fc19.x86_64 abrt-plugin-bodhi-2.1.6-3.fc19.x86_64 abrt-desktop-2.1.6-3.fc19.x86_64 abrt-2.1.6-3.fc19.x86_64 abrt-retrace-client-2.1.6-3.fc19.x86_64 abrt-dbus-2.1.6-3.fc19.x86_64 abrt-addon-xorg-2.1.6-3.fc19.x86_64 abrt-addon-ccpp-2.1.6-3.fc19.x86_64 abrt-addon-python-2.1.6-3.fc19.x86_64 How reproducible: Many times. I don't have an exact count, but I would estimate 3 out of 4 bugs have this problem - admittedly most of the bugs on this machine seem to be specific to gnome-shell. Steps to Reproduce: 1. Experience bug. See ABRT notification. 2. Try to report bug. 3. Problem. Actual results: After running through the gauntlet of reducing the backtrace size, ABRT eventually gives up and is unable to report the bug. Expected results: Give option to report it anyway (even though it's big) or actually reduce the size of the backtrace so it can be reported. Additional info:
I'm not quite sure why this is happening. Would you mind uploading a coredump if it's not terribly big so we can try to reproduce this and/or talk to gnome-shell guys about it?
Sure - specifically what would you like me to upload? I don't know where abrt stores the core dumps.
(In reply to John William from comment #2) > Sure - specifically what would you like me to upload? I don't know where > abrt stores the core dumps. /vart/tmp/abrt/ccpp-<dir>/coredump You can use 'abrt-cli list' to find the path according to executable.
Created attachment 797526 [details] core dump
If it helps, abrt's log while trying to create the backtrace: --- Running report_uReport --- Generating core_backtrace Generating backtrace Backtrace is too big (33561281 bytes), reducing depth to 512 Backtrace is too big (33561281 bytes), reducing depth to 256 Backtrace is too big (33561281 bytes), reducing depth to 128 Backtrace is too big (33561281 bytes), reducing depth to 64 Backtrace is too big (33555685 bytes), reducing depth to 64 Backtrace is too big (33555461 bytes), reducing depth to 64 Backtrace is too big (33555461 bytes), reducing depth to 32 Error: Line 15, column 0: "Thread" header expected ('report_uReport' exited with 1)
Current instruction pointer was pointing to .bss, and gdb's "disassemble" command disasm'ed... entire .bss! >8-----------] The fix we are going with is to fall back to either no disassembly or disassembly of a small area of code. The problem is that the first run will still potentially go insame and try to disassemble many megabytes :( Maybe we should file a RFE for gdb: "make it possible to limit disassebly size"?
(In reply to Denys Vlasenko from comment #6) > Current instruction pointer was pointing to .bss, > and gdb's "disassemble" command disasm'ed... entire .bss! >8-----------] > > The fix we are going with is to fall back to either no disassembly or > disassembly of a small area of code. > > The problem is that the first run will still potentially go insame and try > to disassemble many megabytes :( > > Maybe we should file a RFE for gdb: "make it possible to limit disassebly > size"? Sure, just go ahead and open the RFE in bugzilla and start the discussion.
(In reply to Jiri Moskovcak from comment #7) > Sure, just go ahead and open the RFE in bugzilla and start the discussion. Created bug 1015419 I think Jan didn't fully realize the scope of the problem. My bad: i didn't give him this bug for reference.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.