Red Hat Bugzilla – Bug 995889
"Backtrace is too big - reducing depth to xxx" does not work correctly
Last modified: 2016-01-31 21:22:49 EST
Description of problem:
When reporting many bugs with ABRT, I get something similar to:
Lock file './.lock' is locked by process 6567
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
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):
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.
After running through the gauntlet of reducing the backtrace size, ABRT eventually gives up and is unable to report the bug.
Give option to report it anyway (even though it's big) or actually reduce the size of the backtrace so it can be reported.
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.
You can use 'abrt-cli list' to find the path according to executable.
Created attachment 797526 [details]
If it helps, abrt's log while trying to create the backtrace:
--- Running report_uReport ---
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
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
Thank you for reporting this bug and we are sorry it could not be fixed.