Bug 998948 - core_backtrace addresses in decimal, not hex
core_backtrace addresses in decimal, not hex
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Marko
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-20 08:08 EDT by Steve Tyler
Modified: 2016-01-31 21:23 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-10 10:53:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Steve Tyler 2013-08-20 08:08:38 EDT
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)

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

Version-Release number of selected component (if applicable):

How reproducible:

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 08:22:16 EDT
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 08:41:59 EDT
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."


A work-around might be to format it as a string: { "address": "0x1234abcd" }.
Comment 3 Steve Tyler 2013-08-25 08:05:27 EDT
(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: Infinite and NaN Number Values
Comment 4 Richard Marko 2013-09-10 10:53:30 EDT
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.