Re: gdb seg violation during print command

[Mark Kettenis <kettenis@wins.uva.nl>]

   From: David Cogen <cogen@ll.mit.edu>
   Date: 03 May 2000 12:39:31 -0400

   I have a simple test case which demonstrates this problem. The
   following is a transcript. I trust I have included all necessary
   details?

[ CC'd to gdb@sourceware.cygnus.com, the original message can be found
  in the bug-gdb mailing list archive ]

Excellent!  This is what I see on sparc-sun-solaris2.6 with a GDB
compiled from the trunk (I don't have a build from the 5.0 branch
lying around here right now).  The test program was compiled with
egcs-2.91.66.


GNU gdb 20000204
Copyright 2000 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 "sparc-sun-solaris2.6"...
(gdb) b main
Breakpoint 1 at 0x1a318: file test.cc, line 9.
(gdb) r
Starting program: /tmp/./test 

Breakpoint 1, main () at test.cc:9
9       {
(gdb) p tteesstt11(1)
Cannot resolve function tteesstt11 to any overloaded instance
(gdb)


No segfaults anymore, but the current behaviour seems to be wrong
too.  Any of the C++ guru's know what's happening here?

Mark
From dan@cgsoftware.com Wed May 03 14:10:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com
Subject: Re: gdb seg violation during print command
Date: Wed, 03 May 2000 14:10:00 -0000
Message-id: <g0rze3w2.fsf@dynamic-addr-88-117.resnet.rochester.edu>
References: <200005031637.MAA25467@ll.mit.edu> <200005031759.TAA18350@landau.wins.uva.nl> <snvze4ib.fsf@dynamic-addr-88-117.resnet.rochester.edu> <200005032105.e43L5U300694@delius.kettenis.local>
X-SW-Source: 2000-05/msg00014.html
Content-length: 937

Mark Kettenis <kettenis@wins.uva.nl> writes:


>    > 
> 
>    What version of gdb is this really? IE when is it from?
>    (We've had 20000204 there forever).
> 
> April 25.  But I just tested it with a GDB compiled from sources
> checked out of CVS half an our ago.  No difference.

Okay. And you said egcs 1.1.2, right?

Please "set debug overload 1" and retry, and send me the results.

I suspect the problem is that that version of egcs is marking types with
the wrong sign in the debug info in certain cases, and the
rank_one_type code isn't handling the specific case, and defaulting to
saying it's an incompatible overload.

I ran into this problem once before, and had patches to deal with
these specific comparisons in rank_one_type, but i seem to have lost
them during a file system screwup (I did them in early january).

They were trivial, and i can redo them.

But first, i need to make sure that's the problem.

> 
> Mark
From dan@cgsoftware.com Wed May 03 14:22:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: cogen@ll.mit.edu (David Cogen), Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb seg violation during print command
Date: Wed, 03 May 2000 14:22:00 -0000
Message-id: <bt2ne3cq.fsf@dynamic-addr-88-117.resnet.rochester.edu>
References: <200005031637.MAA25467@ll.mit.edu>
X-SW-Source: 2000-05/msg00015.html
Content-length: 2074

cogen@ll.mit.edu (David Cogen) writes:


First off, your code is broken. You claim to return an int, but don't.
This is what is causing the segfault in gdb.
It's impossible for us to not believe the compiler when it says "this
function returns an int". We expect it to return an int.

In the newer gdb, what'll happen is you'll get no segfault, but a weird number
returned, which will actually the address of the function, which is
the last value we have around, i guess.



> I have a simple test case which demonstrates this problem. The following is a
> transcript. I trust I have included all necessary details?
> 
> redsavina% uname -a
> SunOS redsavina 5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-Enterprise
> redsavina% g++ --version
> 2.95.2
> redsavina% gdb --version
> GNU gdb 4.18
> Copyright 1998 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 "sparc-sun-solaris2.4".
> redsavina% cat test.cc
> #include <iostream>
> 
> int tteesstt11 (int)
> {
>   cerr << "\n";
> }
> 
> int main ()
> {
> }
> 
> redsavina% g++ -g -o test test.cc
> redsavina% gdb -n ./test
> GNU gdb 4.18
> Copyright 1998 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 "sparc-sun-solaris2.4"...
> (gdb) break main
> Breakpoint 1 at 0x1a8a0: file test.cc, line 9.
> (gdb) r
> Starting program: /data/redsavina0/cogen/l/astb/src/util/derive_message_stream_files/./test -input test.strm
> 
> Breakpoint 1, main () at test.cc:9
> 9	{
> (gdb) p tteesstt11(1)
> Segmentation Fault (core dumped)
> redsavina% 
From kettenis@wins.uva.nl Wed May 03 15:43:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: dan@cgsoftware.com
Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com
Subject: Re: gdb seg violation during print command
Date: Wed, 03 May 2000 15:43:00 -0000
Message-id: <200005032243.e43Mh6F00788@delius.kettenis.local>
References: <200005031637.MAA25467@ll.mit.edu> <200005031759.TAA18350@landau.wins.uva.nl> <snvze4ib.fsf@dynamic-addr-88-117.resnet.rochester.edu> <200005032105.e43L5U300694@delius.kettenis.local> <g0rze3w2.fsf@dynamic-addr-88-117.resnet.rochester.edu>
X-SW-Source: 2000-05/msg00016.html
Content-length: 2533

   Reply-To: dan@cgsoftware.com
   Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com
   From: Daniel Berlin <dan@cgsoftware.com>
   Date: 03 May 2000 17:10:37 -0400
   User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/21.1 (Canyonlands)
   Content-Type: text/plain; charset=us-ascii

   Mark Kettenis <kettenis@wins.uva.nl> writes:

   >    > 
   > 
   >    What version of gdb is this really? IE when is it from?
   >    (We've had 20000204 there forever).
   > 
   > April 25.  But I just tested it with a GDB compiled from sources
   > checked out of CVS half an our ago.  No difference.

   Okay. And you said egcs 1.1.2, right?

That's what it is according to the "Timeline" on gcc.gnu.org :-).

   Please "set debug overload 1" and retry, and send me the results.

   sh-2.03$ ./gdb /tmp/test
   GNU gdb 20000204
   Copyright 2000 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 "sparc-sun-solaris2.6"...
   Setting up the environment for debugging gdb.
   .gdbinit:5: Error in sourced command file:
   Function "internal_error" not defined.
   (gdb) set debug overload 1
   (gdb) b main
   Breakpoint 1 at 0x1a318: file test.cc, line 9.
   (gdb) r
   Starting program: /tmp/test 

   Breakpoint 1, main () at test.cc:9
   9       {
   (gdb) p tteesstt1(1)
   Overloaded function instance tteesstt11(int) # of parms 0
   ...Badness @ 0 : 100
   Overload resolution champion is 0, ambiguous? 0
   Cannot resolve function tteesstt11 to any overloaded instance
   (gdb) quit
   The program is running.  Exit anyway? (y or n) y

Does that tell you anything?

   I suspect the problem is that that version of egcs is marking types with
   the wrong sign in the debug info in certain cases, and the
   rank_one_type code isn't handling the specific case, and defaulting to
   saying it's an incompatible overload.

   I ran into this problem once before, and had patches to deal with
   these specific comparisons in rank_one_type, but i seem to have lost
   them during a file system screwup (I did them in early january).

   They were trivial, and i can redo them.

Well, if you can easily fix this, go ahead.  Otherwise it might be
better to concentrate your effeorts on improving support for compilers
that don't have this bug.

Mark
From cogen@ll.mit.edu Thu May 04 09:59:00 2000
From: David Cogen <cogen@ll.mit.edu>
To: dan@cgsoftware.com
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: gdb seg violation during print command
Date: Thu, 04 May 2000 09:59:00 -0000
Message-id: <200005041655.MAA10513@ll.mit.edu>
References: <bt2ne3cq.fsf@dynamic-addr-88-117.resnet.rochester.edu>
X-SW-Source: 2000-05/msg00017.html
Content-length: 874

> First off, your code is broken. You claim to return an int, but don't.
> This is what is causing the segfault in gdb.
> It's impossible for us to not believe the compiler when it says "this
> function returns an int". We expect it to return an int.

Sorry, that's not it. I have also tried the following:

#include <iostream>

int tteesstt11 (int)
{
  cerr << "\n";
  return 4;
}

int main ()
{
}

print tteesstt11(1) from a breakpoint in main() still causes gdb to seg
fault. Indeed, I have tried lots of forms for tteesstt11; they all seg fault.

> In the newer gdb, what'll happen is you'll get no segfault, but a weird number
> returned, which will actually the address of the function, which is
> the last value we have around, i guess.

Have you actually tried this or are you supposing? Where can I get the "newer"
gdb? What version is the "newer" gdb?

-- DavidC