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" <[email protected]> To: "Richard Marko" <[email protected]>, [email protected] 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"; ?
