Bugzilla Bug 97409

Hi,

When I tried to debug a program on the new GDB version, I got a strange error. 
I thought I had figured it out but it turned out only partly true.

I get this error every time:

Attaching to program: /home/gdb/gdbtest, process 14868
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Error while running hook_stop:
Invalid type combination in ordering comparison.
0xb7f79cd8 in read () from /lib/libc.so.6

That goes for any program. It doesn't seem to bother cores (from memory and a 
quick test).



Reproducible: Always
Steps to Reproduce:
1. emerge gdb
2. create a new user (useradd -m testuser for instance)
3. switch to that user and make sure there is a .gdbinit file there (should be).
4. Run a program that doesn't terminate right away (to attach to it's process).
5. gdb <program> <pid>
Actual Results:  
The error mentioned above:

Error while running hook_stop:
Invalid type combination in ordering comparison.

Expected Results:  
No error;

Should just stop the program like usual.

Easy fix: rm the .gdbinit file OR use it as root. Problem goes away.

emerge info:

Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-
2.3.4.20041102-r1, 2.6.11-gentoo-r11 i686)
=================================================================
System uname: 2.6.11-gentoo-r11 i686 AMD Duron(tm)
Gentoo Base System version 1.6.12
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, Jun 26 2005, 18:35:26)]
dev-lang/python:     2.3.5
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.8.5-r3, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/
config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org 
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 alsa apm arts avi berkdb bitmap-fonts crypt cups emboss encode 
foomaticdb fortran gdbm gif gpm gtk2 imlib ipv6 jpeg kde libg++ libwww mad 
mikmod motif mp3 mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png 
python quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-
fonts xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, 
PORTDIR_OVERLAY

*** Bug 97410 has been marked as a duplicate of this bug. ***

*** Bug 97411 has been marked as a duplicate of this bug. ***

What version of gdb are you having a problem with?  Has the issue resolved
itself with newer versions?

This still happens on GDB 6.4, with the .gdbinit file; a simple fix is to rm
the
.gdbinit file from the user's home directory. After that, things seem to work
just fine. 

Interestingly, I've also tried putting the .gdbinit file in a different system
with GDB, and it seemed to fail too (specifically Fedora Core 3). So not sure
if
it's something in the gdb code itself or if it's .gdbinit ...

This only happens on running processes. 

Btw,

I also noticed a couple other things this time I tested it:

#1:

Attaching to program: /home/gdbtester/tester, process 12926
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.

(and on another run of the program):

#2:

Attaching to program: /home/gdbtester/tester, process 12984
Failed to read a valid object file image from memory.

and I have no idea why or what would cause those errors.

At this point in time, I'm not sure what else to provide, but if you let me
know, I'd be happy to help out.

If I am not providing enough info, just let me know as well.

Just went to check status here, and realized I never re-opened after supplying
more info, and I guess I should have.

If any more details are needed, just let me know.

does it only happen when the .gdbinit is in $HOME ?  or does it also happen
with $PWD ?  what do you have in the file (attach your .gdbinit) ?  can you
also post some sample code which you compile & run to reproduce this ?

It still happens when in $PWD (and also in $HOME). Sometimes it's error #1 on
comment 5 below, and sometimes it's error #2 (haven't found a pattern though).

Attaching the .gdbinit file and then the .c file (and compile options I used)
in the next post.

Created an attachment (id=78161) [edit]
the .gdbinit file I have (from gdb6.4)

Here is the .gdbinit file you requested. It's not modified in any way from what
emerge gdb installs.

Created an attachment (id=78162) [edit]
a sample program that fails to be debugged with .gdbinit existing

Used gcc -Wall -g -ggdb3 -o gdbtest gdbtest.c
(and also tried gcc -Wall -g -o gdbtest gdbtest.c)
and then:

Shell #1

./gdbtest

Shell #2

ps aux (to get the PID)
gdb ./gdbtest <PID>

It is not limited to running process only. It also hits me recently after
emerge sometime ago.

The problem is the 'define hook-stop' in .gdbinit. After removed the
followings, the problem goes away.  I am not a big guru in .gdbinit. Could
someone give another pair of eyes? Many Thanks.

define hook-stop
 if ( $SHOW_CONTEXT > 0 )
  context
 end
 if ( $SHOW_NEST_INSN > 0 )
  set $x = $_nest
  while ($x > 0 )
   printf "\t"
   set $x = $x - 1
  end
 end
end

I am no GDB guru, internally or otherwise, but, here's another take on it:

It seems to me it's the comparision (>, etc) in that hook-stop definition. And
if you look in the GDB source, there is a FIXME note near these messages we get
from it (valarith.c, in the value_* functions).

If you changed the > to == (in the .gdbinit file, hook-stop definition), you'd
get a very similar error message when running gdb.

Of course, I might be stating the obvious to the devs.. but maybe this is
useful somehow ?

*** Bug 133162 has been marked as a duplicate of this bug. ***

Created an attachment (id=86725) [edit]
gdbinit-6.2.diff

Please give this a try.
 # CHANGELOG:
+#      Version 6.2-gentoo
+#       $SHOW_CONTEXT variable does not appear to work within defines.
+#       so just show it always. but with dont-repeat set.
+#       taviso - more powerful assemble macro

Seems to work for me (more info printed but that's fine by me):

~ $ gdb ./gdbtest 8705
GNU gdb 6.4
Copyright 2005 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 "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

Attaching to program: /mud/livemud/gdbtest, process 8705
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
_______________________________________________________________________________
     eax:FFFFFE00 ebx:00000000  ecx:B7F30000  edx:00000400     eflags:00000246
     esi:B7F2A760 edi:B7E15AA0  esp:BFC44E94  ebp:BFC44EB8     eip:FFFFE410
     cs:0073  ds:007B  es:007B  fs:0000  gs:0033  ss:007B    o d I t s Z a P c 
[007B:BFC44E94]---------------------------------------------------------[stack]
BFC44EC4 : 00 00 F3 B7  00 04 00 00 - F4 9F F2 B7  60 A7 F2 B7 ............`...
BFC44EB4 : 00 04 00 00  D8 4E C4 BF - 50 2D E7 B7  60 A7 F2 B7 .....N..P-..`...
BFC44EA4 : F4 9F F2 B7  88 3F E7 B7 - 00 00 00 00  00 00 F3 B7 .....?..........
BFC44E94 : B8 4E C4 BF  00 04 00 00 - 00 00 F3 B7  D3 F8 EB B7 .N..............
[007B:B7F2A760]---------------------------------------------------------[ data]
B7F2A760 : 88 22 AD FB  00 00 F3 B7 - 00 00 F3 B7  00 00 F3 B7 ."..............
B7F2A770 : 00 00 F3 B7  00 00 F3 B7 - 00 00 F3 B7  00 00 F3 B7 ................
[0073:FFFFE410]---------------------------------------------------------[ code]
0xffffe410 <__kernel_vsyscall+16>:      pop    %ebp
0xffffe411 <__kernel_vsyscall+17>:      pop    %edx
0xffffe412 <__kernel_vsyscall+18>:      pop    %ecx
0xffffe413 <__kernel_vsyscall+19>:      ret    
0xffffe414 <__kernel_vsyscall+20>:      nop    
0xffffe415 <__kernel_vsyscall+21>:      nop    
------------------------------------------------------------------------------
0xffffe410 in __kernel_vsyscall ()
gdb> bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ebf8d3 in read () from /lib/tls/libc.so.6
#2  0xb7e73f88 in _IO_file_read () from /lib/tls/libc.so.6
#3  0xb7e72d50 in _IO_file_underflow () from /lib/tls/libc.so.6
#4  0xb7e7519b in _IO_default_uflow () from /lib/tls/libc.so.6
#5  0xb7e74f9d in __uflow () from /lib/tls/libc.so.6
#6  0xb7e701e5 in getchar () from /lib/tls/libc.so.6
#7  0x080483c5 in main () at gdbtest.c:5

Seems we forget to merge this patch. It's now fixed in gdb-6.5-r1.ebuild