Unable to debug under 2.6.22 on i386: Failed to read a valid object file image from memory

Bug #74691 reported by Matt Zimmerman on 2006-12-06
40
Affects Status Importance Assigned to Milestone
Debian
Fix Released
Unknown
linux-source-2.6.20 (Suse)
Invalid
Critical
linux-source-2.6.20 (Ubuntu)
High
Ben Collins
linux-source-2.6.22 (Ubuntu)
Critical
Ben Collins

Bug Description

Binary package hint: gdb

I'm unable to use gdb under the 2.6.19 kernel in Feisty. Works fine on a stock Edgy system, doesn't work on an Edgy system with the kernel upgraded.

mizar:[/tmp] gdb sleep
GNU gdb 6.5-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run 300
Starting program: /bin/sleep 300
Failed to read a valid object file image from memory.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGINT, Interrupt.
0xb7f32410 in ?? ()
(gdb) bt
#0 0xb7f32410 in ?? ()
#1 0xbfef2458 in ?? ()
#2 0xb7ddb68c in ?? ()
#3 0x00000000 in ?? ()
(gdb)

Matt Zimmerman (mdz) on 2006-12-06
Changed in gdb:
assignee: nobody → ben-collins
status: Unconfirmed → Confirmed
Ben Collins (ben-collins) wrote :

Confirmed. From what I can tell so far, bfd is getting unexpected info from proc mem files under 2.6.19.

Changed in gdb:
importance: Undecided → High
Ben Collins (ben-collins) wrote :

This appears fixed in 2.6.20 git. So should be ok with next upload.

Changed in gdb:
status: Confirmed → Fix Committed
Sebastien Bacher (seb128) wrote :

doing the same with 2.6.20-1-generic

Ben Collins (ben-collins) wrote :

Please retest against 2.6.20-2 when it is available in the feisty archive.

Changed in linux-source-2.6.19:
status: Fix Committed → Needs Info
Ben Collins (ben-collins) wrote :

Seems to be working now under 2.6.20.

Changed in linux-source-2.6.20:
status: Needs Info → Fix Released

I get the same bad bactktrace under 2.6.20-5:

$ gdb sleep
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run 300
Starting program: /bin/sleep 300
(no debugging symbols found)
Failed to read a valid object file image from memory.
(no debugging symbols found)

Program received signal SIGINT, Interrupt.
0xb7f83410 in ?? ()
(gdb) bt
#0 0xb7f83410 in ?? ()
#1 0xbfd75668 in ?? ()
#2 0xb7e1e68c in ?? ()
#3 0x00000000 in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y

$ uname -r
2.6.20-5-generic

Changed in linux-source-2.6.20:
status: Fix Released → Unconfirmed

I think Linux 2.6.20-6-generic fixes the issue.

Anderson (amg1127) wrote :

I think Linux 2.6.20-6-generic fixes the issue.

Changed in linux-source-2.6.20:
status: Unconfirmed → Fix Released
Martin Pitt (pitti) wrote :

This issue seems to be back on i386 kernels in gutsy. It works fine on amd64 and powerpc for me, but Seb can reproduce it on i386.

Changed in linux-source-2.6.22:
importance: Undecided → High
Shirish Agarwal (shirishag75) wrote :

Ok here's mine :-

shirish@ubuntu:~$ gdb sleep
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run 500
Starting program: /bin/sleep 500
Failed to read a valid object file image from memory.

Program received signal SIGINT, Interrupt.
0xffffe410 in ?? ()
(gdb) bt
#0 0xffffe410 in ?? ()
#1 0xbfaecae8 in ?? ()
#2 0xb7dca68c in ?? ()
#3 0x00000000 in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y
shirish@ubuntu:~$ uname -r
2.6.22-7-generic

I have both gdb-dbgsym as well as coreutils-dbgsym installed . Did CRTL^C while run 500 was happening.

Martin Pitt (pitti) wrote :

For comparison on amd64: with coreutils-dbgsym, I get a good backtrace and no 'Failed to read a valid object file image from memory.' error.

(gdb) bt
#0 0x00002accdc287750 in nanosleep () from /lib/libc.so.6
#1 0x00000000004026b4 in xnanosleep (seconds=<value optimized out>) at xnanosleep.c:101
#2 0x00000000004012ca in main (argc=2, argv=0x1) at sleep.c:148
#3 0x00002accdc20e8e4 in __libc_start_main () from /lib/libc.so.6
#4 0x0000000000400f99 in _start ()

Martin Pitt (pitti) wrote :

I finally downloaded a i386 desktop CD, and confirm Seb's and Shirish's finding.

Changed in linux-source-2.6.22:
status: New → Confirmed
Ben Collins (ben-collins) wrote :

Matthias is investigating if this needs to be fixed in bfd or not.

Changed in linux-source-2.6.22:
assignee: nobody → doko
status: Confirmed → Incomplete
Sebastien Bacher (seb128) wrote :

https://bugzilla.novell.com/show_bug.cgi?id=258433 mentions 'echo 0 > /proc/sys/vm/vdso_enabled' as a workaround

I tried 'echo 0 > /proc/sys/vm/vdso_enabled', and my computer locked up hard. What is a VDSO? Could this lockup be related to FGLRX (it seems that most lockups are)?

When I execute 'echo 0 > /proc/sys/vm/vdso_enabled' with no X server running and fglrx unloaded, I can no longer input anything via keyboard, and I can't connect over SSH, either. Not even the power button works.

What's funny is that I *can* switch VTs... other than that, nothing.

Changed in linux-source-2.6.20:
status: Unknown → Confirmed
Anderson (amg1127) wrote :

By adding "vdso=0" to kernel command line options and rebooting, my system works well and I can get the following backtrace:

[amg1127@amg1127:~]$ gdb sleep
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run 5000
Starting program: /bin/sleep 5000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGINT, Interrupt.
0xb7fa97f2 in 9�t����t��z�:t�1��댍�& () from /lib/ld-linux.so.2
(gdb) bt
#0 0xb7fa97f2 in 9�t����t��z�:t�1��댍�& () from /lib/ld-linux.so.2
#1 0xb7ebee50 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2 0x0804a20a in ?? ()
#3 0xbf92c914 in ?? ()
#4 0x00000000 in ?? ()

The #0 position on stack seems really strange...

After installing coreutils-dbgsym package, I get:

GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run 5000
Starting program: /bin/sleep 5000

Program received signal SIGINT, Interrupt.
0xb7f077f2 in 9�t����t��z�:t�1��댍�& () from /lib/ld-linux.so.2
(gdb) bt
#0 0xb7f077f2 in 9�t����t��z�:t�1��댍�& () from /lib/ld-linux.so.2
#1 0xb7e1ce50 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2 0x0804a20a in xnanosleep (seconds=5000) at xnanosleep.c:101
#3 0x08048f04 in main (argc=2, argv=Cannot access memory at address 0x4
) at sleep.c:148
#4 0xb7da0040 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#5 0x08048b71 in _start ()

Martin Pitt (pitti) wrote :

Too late for a full kernel upload now, unless this is an unintrusive one and does not break ABI.

I respectfully submit that on OS which doesn't let developers debug is not a very useful OS.

If the choice is between breaking ABI (while two months away from 7.10) and breaking the most basic of functionality for an entire Ubuntu release, well, I should hope that the choice would be obvious.

If the ABI is deemed more important, perhaps the default kernel arguments in GRUB could at least be modified to include "vdso=0" (while recognizing that this is a workaround, not a fix)?

On Tue, Aug 07, 2007 at 01:47:06PM -0000, Jon Anderson wrote:
> I respectfully submit that on OS which doesn't let developers debug is
> not a very useful OS.
>
> If the choice is between breaking ABI (while two months away from 7.10)
> and breaking the most basic of functionality for an entire Ubuntu
> release, well, I should hope that the choice would be obvious.

We are in a temporary freeze to prepare a milestone for release and testing,
which means this is an inconvenient time to change the kernel ABI, because
this requires a lengthy process of rebuilds to get everything back into
sync. Besides, as far as I see in this bug report, we don't actually have a
fix to apply, so there's no need to hypothesize about whether it might
change the ABI.

This bug remains open and is targeted for the next milestone. In other
words, don't panic.

--
 - mdz

Ok, so the freeze isn't for Gutsy, but just the next Tribe? That sounds reasonable.

David Tomaschik (matir) wrote :

Definitely still present on 2.6.22-9-generic. Exact same results as above, x86.

Andre Klapper (a9016009) wrote :

i see the same problems in bugzilla.gnome.org, especially for reports from opensuse and debian 2.18, but fedora 7 also is not really useful currently, though not that bad as the other ones.
also see https://bugzilla.novell.com/show_bug.cgi?id=258433 , loïc also commented on that one.

Changed in linux-source-2.6.20:
status: Confirmed → Invalid
Sebastien Bacher (seb128) wrote :

opensuse has fixed the bug with this patch apparently, https://bugzilla.novell.com/attachment.cgi?id=159330

Matthias Klose (doko) on 2007-08-24
Changed in linux-source-2.6.20:
status: Fix Released → Confirmed
Changed in linux-source-2.6.22:
status: Incomplete → Invalid
Martin Pitt (pitti) wrote :

It is not invalid at all, it still happens under Gutsy, and there is a kernel patch for it.

Changed in linux-source-2.6.22:
status: Invalid → Confirmed
Matthias Klose (doko) wrote :

ouch, there was no gdb task ...

Changed in linux-source-2.6.22:
assignee: doko → ben-collins

It seems this bug also affects the Debian kernel packages as well. I added the appropriate Debian BTS bug number. According to that report, this problem persists even with Debian's latest 2.6.22 kernels in Sid.

Henrik Nilsen Omma (henrik) wrote :

No need for a Gutsy task on the Feisty kernel (in fact should 2.6.20 simply be a WontFix?).

Matt Zimmerman (mdz) wrote :

Still happening here, on current Gutsy

Changed in linux-source-2.6.22:
assignee: ben-collins → phillip-lougher
importance: High → Critical

I think I may have stumbled on to something interesting playing around with gdb's settings.

When running inside the gdb command line, but the target program has not yet run, type `set debug target n' where `n' is any whole integer greater than or equal to one. Then proceed to run the program inside gdb with the `run' command.

For me, at least, this method does not produce the `Failed to load valid object from memory' error and instead produces screenfulls of debug information (like one would expect in the first place).

My machine I tried this on is running an up-to-date Debian etch install.

Cheers.

Shirish Agarwal (shirishag75) wrote :

Dunno if its due to J Kyle's thing but now it seems to be ready for debugging, can somebody confirm this?

Adding output as seen from gdb, if somebody wants to do some more tests or something, please lemme know.

I haven't made any change, and I'm not getting the "failed to read..." message.
I think it has been fixed in 2.6.22.11.

Changed in linux-source-2.6.22:
assignee: phillip-lougher → ben-collins
status: Confirmed → Fix Committed
Matti Lindell (mlind) wrote :

This should be fixed in gutsy, since 2.6.22-11.32:
  [Upstream Kernel Changes]
  .
  * i386: allow debuggers to access the vsyscall page with compat vDSO

Steve Langasek (vorlon) on 2007-09-29
Changed in linux-source-2.6.22:
status: Fix Committed → Fix Released

Just cleaning up old kernel tasks. I'm going to go ahead and close this against 2.6.20. Thanks.

Changed in linux-source-2.6.20:
status: Confirmed → Won't Fix
Changed in linux-source-2.6.20 (Suse):
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.