Bug 998948

Summary: core_backtrace addresses in decimal, not hex
Product: [Fedora] Fedora Reporter: Steve Tyler <stephent98>
Component: abrtAssignee: Richard Marko <rmarko>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: abrt-devel-list, ars_1, dvlasenk, iprikryl, jberan, jfilak, jmoskovc, mmilata, mtoman, rmarko, stephent98
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: 2013-09-10 14:53:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
core_backtrace example none

Description Steve Tyler 2013-08-20 12:08:38 UTC 
Created attachment 788461 [details]
core_backtrace example

Description of problem:

The frame addresses in core_backtrace appear to be in decimal, not hex. Ancillary files, such as "maps", have addresses in hex.

>>> hex(140649066616067)
'0x7feb69a75503'

Snippet from attached core_backtrace:
...
      , {   "crash_thread": true
        ,   "frames":
              [ {   "address": 140649066616067
                               ^^^^^^^^^^^^^^^
...

Version-Release number of selected component (if applicable):
abrt-2.1.6-3.fc20
Fedora-20-Nightly-x86_64-Live-desktop-20130816.11-1.iso

How reproducible:
Always.

Steps to Reproduce:
1. Crash a program that abrt handles.

Actual results:
core_backtrace addresses are in decimal.

Expected results:
core_backtrace addresses are in hex.

Additional info:
The attached core_backtrace example was manually attached to:
Bug 998687 - SIGSEGV storm instead of Manual Partitioning

I like the format. Is it JSON?
Comment 1 Michal Toman 2013-08-20 12:22:16 UTC 
Yes, the address is decimal. The format is JSON and unfortunately JSON does not support integers in hexadecimal format (0x123456).
I'm not sure we can do anything about that, we've designed core_backtrace to be easily machine-parseable rather than human-readable.
Comment 2 Steve Tyler 2013-08-20 12:41:59 UTC 
Yes, I meant hex numbers formatted like 0x1234abcd.

And you are right, the JSON web site says, without explanation:

"A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used."

http://www.json.org/

A work-around might be to format it as a string: { "address": "0x1234abcd" }.
Comment 3 Steve Tyler 2013-08-25 12:05:27 UTC 
(In reply to Steve Tyler from comment #2)
...
> A work-around might be to format it as a string: { "address": "0x1234abcd" }.

The json Python module appears to do something similar:

18.2.3.3. Infinite and NaN Number Values
http://docs.python.org/2.7/library/json.html?highlight=json#infinite-and-nan-number-values
Comment 4 Richard Marko 2013-09-10 14:53:30 UTC 
Sorry but as Michal said it was designed to be machine readable and this change would make it human readable at the expense of the former which is not a good idea.

If it would really be useful for you we can probably generate similar human readable file with less bloat.