Re: Better fix for huge backtrace problem?
Yeah, unless you know how to use gdb :)
On 10/03/2013 12:07 PM, Jakub Filak wrote:
Richard, you've told me that it would be much complicated to implement :)
https://github.com/abrt/abrt/pull/716#issuecomment-25525532
Denys, is your simple solution working? Have you tested it?
- Original Message -
From: Denys Vlasenko dvlas...@redhat.com
To: Richard Marko rma...@redhat.com, crash-catcher@lists.fedorahosted.org
Sent: Thursday, October 3, 2013 11:41:22 AM
Subject: Better fix for huge backtrace problem?
https://bugzilla.redhat.com/show_bug.cgi?id=995889
Synopsis:
--- 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)
The currently implemented solution is to remove -ex disassemble
gdb command
args[18] = (char*)-ex;
args[19] = (char*)disassemble;
args[20] = NULL;
...
+/* Disable -ex disassemble, output might be huge preventing
backtrace generation */
+args[18] = NULL;
+args[19] = NULL;
+
But... disasm sometimes does immediately show the problem...
How about just reducing of disassembly range? Instead
of removing the command, how about:
args[19] = (char*)disassemble $pc, +64;
?
Re: Better fix for huge backtrace problem?
Richard, you've told me that it would be much complicated to implement :)
https://github.com/abrt/abrt/pull/716#issuecomment-25525532
Denys, is your simple solution working? Have you tested it?
- Original Message -
From: Denys Vlasenko dvlas...@redhat.com
To: Richard Marko rma...@redhat.com, crash-catcher@lists.fedorahosted.org
Sent: Thursday, October 3, 2013 11:41:22 AM
Subject: Better fix for huge backtrace problem?
https://bugzilla.redhat.com/show_bug.cgi?id=995889
Synopsis:
--- 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)
The currently implemented solution is to remove -ex disassemble
gdb command
args[18] = (char*)-ex;
args[19] = (char*)disassemble;
args[20] = NULL;
...
+/* Disable -ex disassemble, output might be huge preventing backtrace
generation */
+args[18] = NULL;
+args[19] = NULL;
+
But... disasm sometimes does immediately show the problem...
How about just reducing of disassembly range? Instead
of removing the command, how about:
args[19] = (char*)disassemble $pc, +64;
?
