Re: gdb seg violation during print command

Re: gdb seg violation during print command

[Daniel Berlin]

> 
> 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.
Okay.
Well, it works perfectly for me once i add the return. Prints the newline,
then 4.

> 
> > 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? 
How would i know what it did if i didn't try it?

> Where can I get the "newer"
> gdb?

sourceware.cygnus.com

Look at the gdb page.
> What version is the "newer" gdb?
>
You have a few choices.
You can get a 5.0 snapshot, or the main branch.
Doesn't matter, anything newer than February (when i became the C++
maintainer and started fixing this stuff) should work fine.
And does, for me.

On x86 Linux, and BeOS.
 
> -- DavidC
> 

Re: gdb seg violation during print command

[Daniel Berlin]

It's also possible the bug you are experiencing is that the compiler is
putting the line note in the wrong place, and it's not breaking till the
program is really done, and cerr doesn't exist properly.

Try -gdwarf-2, see if it helps.


On Thu, 4 May 2000, David Cogen wrote:

> > 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
> 

Re: gdb seg violation during print command

[David Cogen]

> It's also possible the bug you are experiencing is that the compiler is
> putting the line note in the wrong place, and it's not breaking till the
> program is really done, and cerr doesn't exist properly.
> 
> Try -gdwarf-2, see if it helps.

redsavina% g++ -gdwarf-2 -o test test.cc
ld: fatal: relocation error: R_SPARC_32: file /tmp/ccwCKbbB.o:  symbol <unknown>:  offset 0xfea2c82f is non-aligned

collect2: ld returned 1 exit status
redsavina% 

Thanks for the suggestion. But as you see, it made it worse :)

-- DavidC
From dan@cgsoftware.com Thu May 04 12:45:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: David Cogen <cogen@ll.mit.edu>
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, cogen@poblano
Subject: Re: gdb seg violation during print command
Date: Thu, 04 May 2000 12:45:00 -0000
Message-id: <Pine.LNX.4.10.10005041243050.28288-100000@propylaea.anduin.com>
References: <200005041936.PAA09829@ll.mit.edu>
X-SW-Source: 2000-05/msg00022.html
Content-length: 698

Errr, i forgot you are on a sparc.
Hmmmmm.

Try adding a line or three to main that do nothing.

On Thu, 4 May 2000, David Cogen wrote:

> > It's also possible the bug you are experiencing is that the compiler is
> > putting the line note in the wrong place, and it's not breaking till the
> > program is really done, and cerr doesn't exist properly.
> > 
> > Try -gdwarf-2, see if it helps.
> 
> redsavina% g++ -gdwarf-2 -o test test.cc
> ld: fatal: relocation error: R_SPARC_32: file /tmp/ccwCKbbB.o:  symbol <unknown>:  offset 0xfea2c82f is non-aligned
> 
> collect2: ld returned 1 exit status
> redsavina% 
> 
> Thanks for the suggestion. But as you see, it made it worse :)
> 
> -- DavidC
> 

Re: gdb seg violation during print command

[David Cogen]

> If C++ is your main language, i would suggest using the 5.0 branch until
> 5.0 is released (we are in release mode, have been for a few weeks. So 5.0
> is quite stable).  

I just downloaded, built, and tried GNU gdb 20000503. Now when I do print
tteesstt11(1) I no longer get the seg violation in gdb. 

:)

But now the other problem surfaces: "Cannot resolve function tteesstt11 to any
overloaded instance."

Apparently this problem was not related to class member functions (as I
implied earlier) but is an inability to evaluate any call to a C++ function,
even globals.

I also tried print ::tteesstt11(1); same error.

:(

Any idea what this might mean? Should I write this up as a detailed bug
report?

-- DavidC

Re: gdb seg violation during print command

[David Cogen]

> 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

Re: gdb seg violation during print command

[Mark Kettenis]

   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