Created attachment 532848 [details] actual backtrace Description of problem: When trying to report a "crash" triggered against a python program, abrt doesn't allow me to upload the bug report. Version-Release number of selected component (if applicable): abrt-2.0.3-6.fc15 Actual results: Using abrt-cli: Select analyzer: 1 Analyzing coredump 'coredump' All 109 debuginfo files are available Backtrace is generated and saved, 45447 bytes Backtrace parsing failed for . 8:4: Frame header variant not recognized. (...) Reporting disabled because the backtrace is unusable Please try to install debuginfo manually using the command: "debuginfo-install PackageKit-yum-0.6.17-1.fc15" and try again Problem reported via 1 report events (1 errors) Additional info: all debuginfo were installed, even those for PackageKit-yum.
I wonder why some frames in the attached backtrace are missing the function offset: #0 slot_tp_getattr_hook (self=<YumAvailableP....) at /usr/src/debug/Python-2.7.1/Objects/typeobject.c:5436 #3 call_function (oparg=<optimized out>, ... #4 PyEval_EvalFrameEx (f=<op... I haven't seen this format before. Can it be caused by "core file may not match specified executable file" as noted on the first line of the backtrace? Some frames from the same backtrace contain the function offset as expected: #1 0x0000003a2a8dcf46 in PyEval_EvalFrameEx ... #2 0x0000003a2a8e0098 in fast_function (nk=... #5 0x0000003a2a8e0098 in fast_function (nk... #23 0x0000003a2a8fc1e0 in PyRun_FileExFlags (fp...
(In reply to comment #1) > I wonder why some frames in the attached backtrace are missing the function > offset: > > #0 slot_tp_getattr_hook (self=<YumAvailableP....) at vs. > #23 0x0000003a2a8fc1e0 in PyRun_FileExFlags (fp... Because those functions are inlined. See `info frame' there. Parsing the ever changing output of GDB backtraces will never work. ABRT should consumer machine-parseable output. Tom recommended Python formatter of the GDB output: https://fedorahosted.org/pipermail/crash-catcher/2011-March/001614.html Another possibility is to use MI with standardized format of frames info: http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Frame-Information.html#GDB_002fMI-Frame-Information There exist some MI libraries out there. Still the text GDB output of backtraces should be output for humans.
Created attachment 532853 [details] content of the report (coredump and such)
(In reply to comment #2) > Because those functions are inlined. See `info frame' there. Thanks. > Parsing the ever changing output of GDB backtraces will never work. > ABRT should consumer machine-parseable output. We will likely switch to a Python formatter in future. The formatter will use the same general syntax as the bt command. Currently, btparser is flexible enough to handle all Fedora backtraces except this one :) > Tom recommended Python formatter of the GDB output: > https://fedorahosted.org/pipermail/crash-catcher/2011-March/001614.html > > Another possibility is to use MI with standardized format of frames info: > http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Frame-Information.html#GDB_002fMI-Frame-Information > There exist some MI libraries out there. > > Still the text GDB output of backtraces should be output for humans.
Fixed in git: commit feb5e31041be1aed73a5c5e7a740bd62ff0f544b Author: Karel Klic <kklic> Date: Mon Jan 23 19:05:32 2012 +0100 rhbz#752811: Extend parser to handle frames representing inlined code.