SegvAnalysis: Failure: invalid literal for int() with base 16: '='

[Marius Gedminas]

Apport sometimes gets confused when analyzing a core dump:

    SegvAnalysis: Failure: invalid literal for int() with base 16: '='

I'm attaching the crash file (sans base64-encoded core dump) that contains this and some other wonderful examples, like

    Registers: $6 = 0x0
    ThreadStacktrace: $9 = 0x4 <error: Cannot access memory at address 0x4>
    Stacktrace: No symbol "__nih_abort_msg" in current context.

and the Disassembly: field containing the actual stack trace, after the disassembly itself.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: apport 2.17.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri May 8 10:17:40 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-07-25 (1016 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to vivid on 2015-04-23 (14 days ago)

[Marius Gedminas (mgedmin)]

You can see the Disassembly: field contains

     $2 = -99Python Exception <class 'TypeError'> iter() returned non-iterator of type '_iterator':

which is missing a newline. This breaks apport's output splitting logic.

The TypeError shows up because of bug 1449389. I think it gets printed into the standard error, which is then smushed together with the standard output in a somewhat random way.

[Marius Gedminas (mgedmin)]

A simple fix would be to modify apport.report.Report.add_gdb_info() to use

     _command_output(..., stderr=subprocess.PIPE )

if we don't mind ignoring gdb's stderr.

[Marius Gedminas (mgedmin)]

I think I got a better fix in the linked Bazaar branch. I'm not sure how to test it: I have the crash file with the base64-encoded core and incorrectly-decoded fields, how can I convince apport (in a bzr checkout) re-interpret it?

[Marius Gedminas (mgedmin)]

I think this output parsing bug bit me again today:

SegvAnalysis: Skipped: missing required field "Disassembly"
SourcePackage: gdm
Stacktrace:
 => 0x417010: mov 0x8(%r15),%rcx
    0x417014: test %rcx,%rcx
    0x417017: je 0x41709f
    0x41701d: mov (%rcx),%rbx
    0x417020: mov 0x8(%rcx),%r15
    0x417024: mov %rbx,%rdi
    0x417027: callq 0x414380
    0x41702c: cmp %rax,%rbp
    0x41702f: jne 0x417010
    0x417031: test %rbx,%rbx
    0x417034: je 0x41709f
    0x417036: test %r14,%r14
    0x417039: je 0x41705c
    0x41703b: mov $0x50,%esi
    0x417040: mov %rbx,%rdi
    0x417043: callq 0x40a6c0 <g_type_check_instance_cast@plt>
StacktraceTop:

This looks like a misalignment of the fields to me.

[Marius Gedminas (mgedmin)]

Bug 1374544 might be a duplicate of this one.

[Tim Lunn (darkxst)]

so long as the crash report has previously been processed by ubuntu-bug, you can just feed it directly to apport-retrace

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.