ld-2.16.so crashed with SIGSEGV in <unavailable> in <unavailable> in ??()

[Steve Langasek]

I have no idea why anything is running x32 code on my system. This happened during a system upgrade to raring.

ProblemType: Crash
DistroRelease: Ubuntu 13.04
Package: libc6-x32 2.16-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-22.34-generic 3.5.7.2
Uname: Linux 3.5.0-22-generic x86_64
ApportVersion: 2.8-0ubuntu2
Architecture: amd64
Date: Fri Jan 25 08:03:08 2013
Disassembly: value is not available
ExecutablePath: /libx32/ld-2.16.so
InstallationDate: Installed on 2010-09-24 (854 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MarkForUpload: True
ProcCmdline: /libx32/ld-linux-x32.so.2 --verify /lib/firmware/cis/tamarack.cis
ProcMaps:
 f7741000-f7742000 r-xp 00000000 00:00 0 [vdso]
 f7742000-f7763000 r-xp 00000000 fc:0f 526652 /libx32/ld-2.16.so
 f7962000-f7964000 rw-p 00020000 fc:0f 526652 /libx32/ld-2.16.so
 ff92a000-ff94b000 rw-p 00000000 00:00 0 [stack]
SegvAnalysis: Failure: invalid literal for int() with base 16: '*value'
Signal: 11
SourcePackage: eglibc
Stacktrace:
 #0 <unavailable> in ?? ()
 PC unavailable, cannot determine locals.
 Backtrace stopped: not enough registers or memory available to unwind further
StacktraceTop: <unavailable> in ?? ()
ThreadStacktrace:
 .
 Thread 1 (LWP 31864):
 #0 <unavailable> in ?? ()
 PC unavailable, cannot determine locals.
 Backtrace stopped: not enough registers or memory available to unwind further
Title: ld-2.16.so crashed with SIGSEGV in <unavailable> in ??()
UpgradeStatus: Upgraded to raring on 2013-01-25 (0 days ago)
UserGroups:

[Apport retracing service (apport)]

Stacktrace:
 #0 <unavailable> in ?? ()
 PC unavailable, cannot determine locals.
 Backtrace stopped: not enough registers or memory available to unwind further
StacktraceSource: #0 <unavailable> in ?? ()
StacktraceTop: <unavailable> in ?? ()
ThreadStacktrace:
 .
 Thread 1 (LWP 31864):
 #0 <unavailable> in ?? ()
 PC unavailable, cannot determine locals.
 Backtrace stopped: not enough registers or memory available to unwind further

[Adam Conrad (adconrad)]

I'm not sure there's much I can do about x32 binaries exploding on kernels without x32 support. Have you considered a raring kernel with that raring glibc of yours? :)

[Steve Langasek (vorlon)]

This happened on upgrade to raring, and the failing command isn't something that I ran myself. Nothing in the upgrade should be relying on x32 support.

[Adam Conrad (adconrad)]

Yeah, I'm not entirely sure what's running the x32 ld.so in the first place (maybe ldconfig?) and we can certainly look into that, but the fact remains that /libx32/ld-linux-x32.so.2 is just plain going to crash on a kernel that doesn't support it. If running it turns out to be an unavoidable side-effect of having it installed, I wonder if we can teach apport to at least ignore this exact trace pattern, so users don't get bugged about it and the eglibc bug list isn't filled with duplicates.

[Launchpad Janitor (janitor)]

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

[Adam Conrad (adconrad)]

Of course, I also can't sort out why ldconfig would be walking /lib/firmware (it doesn't here), so that's another mystery on top of the mystery. What *is* doing that?

[Adam Conrad (adconrad)]

ldd would exhibit this behaviour (since it cycles through all three variants of ld.so to see if a binary is valid, and the first two would say "nu uh" before the third crashes), but... What's running ldd recursively on /lib/firmware?

[Adam Conrad (adconrad)]

Oh, hah. It's initramfs-tools doing library reduction, bet. This doesn't explain the one duplicate of the bug where it was operating on /usr/bin/software-center, but that was probably a manual ldd invocation.

All the others are operating on things that end up in initrds. This can probably be worked around there.