Bug 998948 - core_backtrace addresses in decimal, not hex
Summary: core_backtrace addresses in decimal, not hex
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Marko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-20 12:08 UTC by Steve Tyler
Modified: 2016-02-01 02:23 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-10 14:53:30 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
core_backtrace example (29.55 KB, text/plain)
2013-08-20 12:08 UTC, Steve Tyler
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.