Bug 752811

Summary: abrt failed to parse python backtrace produced by gdb
Product: [Fedora] Fedora Reporter: Yann Droneaud <yann>
Component: btparserAssignee: Karel Klíč <kklic>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: low    
Version: 15CC: dvlasenk, iprikryl, jan.kratochvil, jmoskovc, kklic, mmilata, mtoman, npajkovs, pmuldoon, rvokal, tromey
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-14 11:28:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 744774    
Attachments:
Description Flags
actual backtrace
none
content of the report (coredump and such) none

Description Yann Droneaud 2011-11-10 13:48:08 UTC
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.

Comment 1 Karel Klíč 2011-11-10 14:01:32 UTC
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...

Comment 2 Jan Kratochvil 2011-11-10 14:28:54 UTC
(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.

Comment 3 Yann Droneaud 2011-11-10 14:51:19 UTC
Created attachment 532853 [details]
content of the report (coredump and such)

Comment 4 Karel Klíč 2011-11-23 16:26:42 UTC
(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.

Comment 5 Jiri Moskovcak 2012-02-01 14:05:48 UTC
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.