HDTenEightyP/NetNews huggingface dataset:
From: Josh.PRitikin@c.gp.cs.cmu.edu
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 21:32:02 GMT

I've run into a gdb bug. The problem occurs here:

2070                  name = type_name_no_tag (context);
2071                  if (name == 0)
2072                    {
2073                      complain (&invalid_cpp_type_complaint, symnum);
2074                      TYPE_NAME (context) = name;
2075                    }
2076                  list->field.name = obconcat (prefix, name, "");
#0  read_struct_type (pp=0xf7fff354, type=0x24) at buildsym.c:2074

If name == 0 then it goes through the complain spoo but dies on
obconcat. I looked at the whole function and didn't see an obvious way
to recover. Here's a backtrace:

(gdb) bt
#0  read_struct_type (pp=0xf7fff354, type=0x24) at buildsym.c:2074
#1  0x56ed8 in read_type (pp=0xf7fff354) at buildsym.c:1839
#2  0x55714 in define_symbol (valu=0,
    string=0x152194 "slist_element:t23=s12anext:22,0,32;aprev:22,32,32;$vf23:24=
*25=ar1;0;1;17,64;next::26=##18;:;2A.;__as::27=##28=&23;:RT0;2A.;dup::26:;2A*-21
47483647;23;;;~%23;", desc=0, type=128) at buildsym.c:1137
#3  0x61668 in process_one_symbol (type=128, desc=0, valu=0,
    name=0x152194 "slist_element:t23=s12anext:22,0,32;aprev:22,32,32;$vf23:24=*2
5=ar1;0;1;17,64;next::26=##18;:;2A.;__as::27=##28=&23;:RT0;2A.;dup::26:;2A*-2147
483647;23;;;~%23;", offset=0) at ./dbxread.c:1612
#4  0x60d74 in read_ofile_symtab (objfile=0x135248,
    stringtab=0x73a4 "P'?tP\a?t"?\022", stringtab_size=149439,
    sym_offset=29604, sym_size=12036, text_offset=39104, text_size=15056,
    offset=0) at ./dbxread.c:1238
#5  0x605d0 in psymtab_to_symtab_1 (pst=0x17d260, stringtab=0x14b008 "",
    stringtab_size=149439, sym_offset=204800) at ./dbxread.c:1020
#6  0x608f8 in dbx_psymtab_to_symtab (pst=0x17d260) at ./dbxread.c:1124
#7  0x2fa18 in psymtab_to_symtab (pst=0x17d260) at symfile.c:464
#8  0x2a654 in lookup_symbol (name=0xf7fff660 "lazy_add", block=0xf7fff660,
    namespace=2, is_a_field_of_this=0x0, symtab=0x0) at symtab.c:1027
#9  0x2c384 in decode_line_1 (argptr=0xf7fff79c, funfirstline=1,
    default_symtab=0x0, default_line=0) at symtab.c:1903
#10 0x98b4 in break_command_1 (arg=0x131014 "next", tempflag=0, from_tty=1)
    at breakpoint.c:1301
#11 0x9c68 in break_command (arg=0x13100a "lazy_add::next", from_tty=1)
    at breakpoint.c:1385
#12 0x341c in execute_command (p=0x13100a "lazy_add::next", from_tty=1)
    at main.c:797
#13 0x36bc in command_loop () at main.c:858
#14 0x31bc in main (argc=2, argv=0xf7fffa2c) at main.c:735

I don't know how to easily reproduce this, but I'll work on that if this
isn't enough to fix the bug.

thanks, joshp

Newsgroups: gnu.gdb.bug
From: steinarb@idt.unit.no (Steinar Bang)
Subject: Why gdb 4.4 only works with gcc 2.1 with -O2?
Organization: Norwegian Institute of Technology, Trondheim, Norway
Distribution: gnu
Date: Tue, 14 Apr 1992 19:46:03 GMT

Platform: Sun Sparc, sun os 4.x, gdb 4.4, gcc 2.1 (C++), GNU emacs 18.58

I had the following weird behavior, which I didn't find any
explanation for in the gdb TODO or README files:

 When compiling with the -O2 directive the compiled program seemed run
 fine under gdb, inside emacs.

 When I attempted to compile without any optimization (to get away
 from the weird jumps in the control flow) the following happened: o
 gdb under emacs didn't take the gdb-break command. When I attempted
 to run it using C-x SPC, or using M-x gdb-break nothing happened in
 the gdb buffer.  o After a while the entire gdb process coredumped,
 whether anything was happening or not.

 When I recompiled with -O2 it seemed to be working again (i.e. the
 gdb-break command worked, it didn't coredump by itself).

 The -O2 generated code was a bit smaller than the un-optimized code: 
   58xx xxx bytes vs. 59xx xxx
 The code were linked with two libraries compiled with -g -O2

 I was running with C++ code in .c files, which may have created some
 gdb mode problems.

If this is a known problem, can anyone please mail me the work-around.
If nobody else has seen these problems I can meddle around with this
to see if I can find what causes it and/or give a more complete bug
report (in the meanwhile I am debugging using -O2 generated code :-).

- Steinar

Newsgroups: gnu.gdb.bug
From: wohler@sap-ag.DE (Bill Wohler)
Subject: gdb on hp9000s720 or hp9000s870?
Reply-To: Bill Wohler <wohler@sap-ag.de>
Organization: SAP AG, Walldorf, Germany
Distribution: gnu
Date: Thu, 16 Apr 1992 08:51:16 GMT

  i was unsuccessful in generating a gdb that works on either of the
  above machines, whose "file" output produces:

	PA-RISC1.1 shared executable
	s800 executable

  respectively.  i'd be grateful if anyone could offer any hints.  
  even if "it isn't supported yet," i would like to beta-test a
  version if someone is working on it.

Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler>
Heidelberg Red Barons Ultimate Frisbee Team

Newsgroups: gnu.gdb.bug
From: mly@ai.mit.edu (Richard Mlynarik)
Subject: "break / file / info break" still losing in GDB 4.5
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 00:29:54 GMT

This must surely be the single biggest screw in GDB.  It bites me at
least once a day.  I counldn't believe it wasn't fixed for 4.5.

To lose, run gdb on some file, set some breakpoints, run, recompile
the executable, use the "file" command to snag the new executable,
then type "info break".  Bye bye GDB.



Core was generated by `gdb'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x0.
#0  0x336a4 in fputs_filtered (linebuffer=0x1<Address 0x1 out of bounds>, 
    stream=0xc1e94) at utils.c:958
958     if (stream != stdout
(gdb) bt
#0  0x336a4 in fputs_filtered (linebuffer=0x1<Address 0x1 out of bounds>, 
    stream=0xc1e94) at utils.c:958
#1  0x8a84 in breakpoint_1 (bnum=-1, allflag=0) at breakpoint.c:1059
#2  0x8bf0 in breakpoints_info (
    bnum_exp=0xffffffff<Address 0xffffffff out of bounds>, from_tty=1)
    at breakpoint.c:1110
#3  0x38c4 in execute_command (p=0xd900f "", from_tty=1) at main.c:882
#4  0x3a84 in command_loop () at main.c:943
#5  0x36c4 in main (argc=5, argv=0xf7ffefac) at main.c:820

Newsgroups: gnu.gdb.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: gdb dumps core when reading GCC 2.1-produced symbol table
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 19:35:44 GMT

gdb dumps core when reading GCC 2.1-produced symbol table (sparc, SunOS 4.1.2).
I got this when trying to build InterViews.
Here's how to reproduce the bug.

    $ cat u.cc
    class ivResource   {
    public:
	ivResource  ();
	virtual ~ivResource  ();

	void ref() const;

	static void ref(const ivResource  *);

	void Reference() const { ref(); }
    };
    void ivResource::ref() const {}
    main() { return 0; }
    $ gcc -g u.cc
    $ gdb a.out
    GDB is free software and you are welcome to 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.
    GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
    (gdb) b main
    Memory fault - core dumped

Apparently GCC isn't putting out the right kind of symbol table data.  I'll
submit a bug report (and patch) to bug-gcc about this GCC bug.  However, even
if GCC puts out bad data, GDB shouldn't dump core.

Here is a patch.  The old version of the code set TYPE_NAME (context) to 0,
but it is already guaranteed to be 0, so that assignment isn't necessary.

===================================================================
RCS file: buildsym.c,v
retrieving revision 4.4.1.1
retrieving revision 4.4.1.2
diff -c -r4.4.1.1 -r4.4.1.2
*** buildsym.c	1992/02/11 23:44:03	4.4.1.1
--- buildsym.c	1992/04/10 19:31:44	4.4.1.2
***************
*** 2071,2077 ****
  	      if (name == 0)
  		{
  		  complain (&invalid_cpp_type_complaint, symnum);
! 		  TYPE_NAME (context) = name;
  		}
  	      list->field.name = obconcat (prefix, name, "");
  	      p = ++(*pp);
--- 2071,2077 ----
  	      if (name == 0)
  		{
  		  complain (&invalid_cpp_type_complaint, symnum);
! 		  name = "unknown";
  		}
  	      list->field.name = obconcat (prefix, name, "");
  	      p = ++(*pp);

Newsgroups: gnu.gdb.bug
From: stuart@coral.cs.jcu.edu.au (Stuart Kemp)
Subject: gdb-4.5: doesn't read 'core' file correctly
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 17 Apr 1992 00:09:35 GMT

Using gdb-4.5 on DECstation 5000, Ultrix 4.2b.
configured for mips-dec-ultrix

Command line:

	gdb test core

Output from gdb:

---------------------------------------------------------
...
GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
Core was generated by `test'.
Can't find registers in core file

Cannot access memory at address 0xfffffffc.
Setting up the environment for debugging gdb.
Function fatal not defined.
(gdb)
---------------------------------------------------------

A 'where' gives nothing.

If you use 'gdb test' and run the program, things okay.


-SRK


Newsgroups: gnu.gdb.bug
From: larrym@tv.tv.tek.COM
Subject: User defined command bug in gdb 4.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 03:52:28 GMT

I found a low priority bug in the code that handles user commands in gdb 4.4.
It affects all systems and all targets.

The code in lookup_cmd_1(), called by lookup_cmd() to compare a command
entered by the user with all possible commands in the command list, always
maps user input to lower case.  Thus it will only match command names in
the list that are in lower case, as are all standard gdb commands.

The define_command() routine to add user defined commands to the command
list does not map to lower case.  Thus the user can define a command in
upper or mixed case, it will be shown by "help user", but when an attempt
is made to use the command, gdb responds with an undefined command error
message.

My fix was to copy the "map to lower case" code from lookup_cmd_1() and
insert it into define_command() just before the call to savestring().
This is known to be safe since the check for conflicts with existing
command names was made using a call to lookup_cmd(), which already
mapped the name to lower case (but threw away the result).

Results of "rcsdiff -c main.c" attached below.

				    Thank you very much,
				    Larry Morandi

US Mail:    Larry Morandi, Television Division, Tektronix, Inc.
            P.O. Box 500,    M.S. 58-639,    Beaverton OR 97077
E-Mail:     larrym@tv.tv.tek.com         Phone:    503-627-6002

==========================================================================
*** /tmp/,RCSt1a03722	Wed Apr  8 10:43:07 1992
--- main.c	Tue Apr  7 19:02:45 1992
***************
*** 1552,1558 ****
  End with a line saying just \"end\".\n", comname);
        fflush (stdout);
      }
!   comname = savestring (comname, strlen (comname));
  
    cmds = read_command_lines ();
  
--- 1552,1576 ----
  End with a line saying just \"end\".\n", comname);
        fflush (stdout);
      }
!   /* Bug fix to release 4.4: Since commands are always converted
!      to lower case for comparison with command structures (by the
!      lookup_cmd() and lookup_cmd_1() routines), it makes no sense
!      to save a new user command with upper case.  The command will
!      never be found.  So copy command name into a local temporary,
!      converting to lower case as we go.  */
!     { /* block for fix */
!       int len = strlen(comname);
!       int tmp;
!       char *newcomname = (char *) alloca (len + 1);
!       for (tmp = 0; tmp < len; tmp++)
! 	{
! 	  char x = comname[tmp];
! 	  newcomname[tmp] = (x >= 'A' && x <= 'Z') ? x - 'A' + 'a' : x;
! 	}
!       newcomname[len] = '\0';
!       comname = savestring (newcomname, len);
!     } /* end of block for fix */
! /*  comname = savestring (comname, strlen (comname));	/* original line, before fix */
  
    cmds = read_command_lines ();
  

Newsgroups: gnu.gdb.bug
From: bd@kepler.unh.edu
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 04:54:30 GMT

when using the next command in a C++ program that works.  In
particular, in the code seguence 

                inFile.open( ... );
                if ( inFile )
                  {
                  ...

the gdb command "next" at the if ( inFile ) command causes
a segmentation fault.  See the script run below.

Our Machine: DEC System 5500 using a MIPS processor
and running  ULTRIX V4.2A (REV. 47) System #6
             VWS V4.2 (Rev. 272)

The program was compiled using GNU CC Version 2.0
GDB was compiled using 'cc'.
We are using GDB Version 4.5.

% cat Melville
M
 e
  v
   i
    l 
     l
      e
% cat lip.cc
#include <iostream.h>
#include <fstream.h>

main()
{
   ifstream inFile;

   inFile.open( "Melville", ios::in );
   if ( inFile )
     {
     char ch;
     while ( inFile.get(ch) ) cout.put(ch);
     }
   inFile.clear();
   inFile.close();
   return 0;
}
% g++ -g lip.cc
% a.out
M
 e
  v
   i
    l 
     l
      e
% gdb a.out
GDB is free software and you are welcome to 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.
GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) break lip.cc:8
Breakpoint 1 at 0x40021c: file lip.cc, line 8.
(gdb) run
Starting program: /cs_mnt/users/bd/OOP/a.out 

Breakpoint 1, main () at lip.cc:8
8	   inFile.open( "Melville", ios::in );
(gdb) n
9	   if ( inFile )
(gdb) n
Segmentation fault
script done on Wed Apr 15 09:29:35 1992

Newsgroups: gnu.gdb.bug
From: ea08+@andrew.cmu.edu (Eric A. Anderson)
Subject: Gdb Bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 14:33:55 GMT

I have run across a problem in gdb doing back traces.
(gdb) bt
#0  LineObject::CtrlPointsChanged (this=0x89d20, which=0) at LineObject.cc:177
#1  0xd13c in Object::movectrlpoint (this=0x89d20, num=0, dx=0, dy=3)
    at Object.cc:157

Program received signal 11, Segmentation fault
0x599a4 in read_struct_type (pp=0xf7fff054, type=0x3150e0) at buildsym.c:2475
2475            TYPE_NFN_FIELDS_TOTAL (TYPE_BASECLASS (type, i));
(gdb)
The bug was found in gdb-4.4
          -Eric 
*********************************************************
"Men, after all, are inherently weasels"
	   -In "Earth", by David Brin
"Yes, you're very smart.  Shut up."
           -In "The Princess Bride"
*********************************************************

Newsgroups: gnu.gdb.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: display a: :b still crashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 04:44:28 GMT

The following patch, which I submitted a few weeks ago for gdb 4.4, is
also necessary for gdb 4.5.  Without the patch, 

display A::b

will crash gdb, when debugging C++ code in which A is a class and b is
a static member datum of that class.

Well, maybe it'll make gdb 4.6.  Sigh.

Doug Moore
(dougm@cs.rice.edu)

*** expprint.c~	Tue Mar  3 17:22:35 1992
--- expprint.c	Mon Apr 13 23:39:24 1992
***************
*** 76,87 ****
      case OP_SCOPE:
        myprec = PREC_PREFIX;
        assoc = 0;
!       (*pos) += 2;
!       print_subexp (exp, pos, stream,
! 		    (enum precedence) ((int) myprec + assoc));
        fputs_filtered (" :: ", stream);
        nargs = strlen (&exp->elts[pc + 2].string);
!       (*pos) += 1 + (nargs + sizeof (union exp_element)) / sizeof (union exp_element);
  
        fputs_filtered (&exp->elts[pc + 2].string, stream);
        return;
--- 76,85 ----
      case OP_SCOPE:
        myprec = PREC_PREFIX;
        assoc = 0;
!       type_print (exp->elts[pc + 1].type, "", stream, 0);
        fputs_filtered (" :: ", stream);
        nargs = strlen (&exp->elts[pc + 2].string);
!       (*pos) += 4 + (nargs + sizeof (union exp_element)) / sizeof (union exp_element);
  
        fputs_filtered (&exp->elts[pc + 2].string, stream);
        return;

Newsgroups: gnu.gdb.bug
From: ross@fatman.UUCP (Ross Thomas)
Subject: gdb and Sun ANSI C
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 02:32:38 GMT

G'day,

We seem to be having a problem getting gdb to operate at all when we
compile and link our commands with the new Sun ANSI C compiler. Gdb fails
to even execute a 'list' command on 'main' upon entry. The symptom is that
gdb takes a core dump with signal 11 (SIGSEGV). Similarly, attempting to
set a breakpoint at a function name symbol drops core with a signal SEGV.

I'm hoping that you may have heard of this already. If not, I'll go ahead
and generate test cases and other stuff necessary for you guys and gals
to (hopefully) resolve this.

Yours in hope,

Ross Thomas.

-- 
Ross Thomas             | +510 283 4973      | ross@bit.com
BIT, Inc.               | +510 283 4975 fax  | Ozzies do it from down-under.
1003 Oak Hill Rd.       | +510 284 9297 home | Australia, Australia, Australia,
Lafayette, CA 94549 USA |                    | Australia, we love you. Amen.

Newsgroups: gnu.gdb.bug
From: dcmartin@fascet.msi.com (David C. Martin)
Subject: GDB 4.4 and IRIX 4.0.1+
Reply-To: dcmartin@msi.com
Organization: Molecular Simulations, Inc.
Distribution: gnu
Date: Thu, 9 Apr 1992 16:38:38 GMT

I have an Iris Indigo/Elan running 4.0.2 and would like to use GDB; however,
although I can get the program to compile, it does not actually run the 
program, it just sits there.

The only thing I needed to do to get it to compile was configure w/
mips-sgi-irix and then edit one file to ifdef the declaration of psignal() 
since it didn't match the one in signal.h.  Does anyone have gdb running on 
the indigo and could give me pointers/patches?  Thanks.

dcm
--
--
Molecular Simulations, Inc.			mail: dcmartin@msi.com
796 N. Pastoria Avenue				uucp: uunet!dcmartin
Sunnyvale, California 94086			at&t: 408/522-9236

Newsgroups: gnu.gdb.bug
From: jbryans@beach.csulb.edu (Jack Bryans)
Subject: gdb 4.4 vs ultrix 4.2
Organization: Cal State Long Beach
Distribution: gnu
Date: Wed, 8 Apr 1992 20:35:50 GMT

On a DEC 5810, w/Ultrix 4.2, gdb 4.4 was made w/an ordinary
"./configure decstation", followed by a vanilla make.  Make 3.62 was used &
bison 1.16 could be found in /usr/local/bin.

When executed w/a core file, gdb reports:
"Can't find registers in core file"
and doesn't produce a backtrace.  Using the same core file, dbx had no
problems finding registers or backtracing.

Are there any patches?

Thanks,
Jack

Newsgroups: gnu.gdb.bug
From: uphya001@unibi.hrz.uni-bielefeld.de (0107)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 16:43:19 GMT

There are some problems installing GDB 4.4 on our machine. We are running
MACH 2.6 on a i486 with 20MB memory. 
We configure with the following command:
	- ./configure i386-mach
After building gdb, it's not able to read the object-file-information for
debugging, although compiling with gcc 2.1.
It seems that the file which contains the systen-specific object-formats is
false or missing. Please can you help me?

Thank you very much.


Newsgroups: gnu.gdb.bug
From: lextrait@essi.cerisi.fr (Lextrait Vincent)
Subject: gdb4.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 13:53:17 GMT

I have just compiled gdb4.4 package with an old version of gcc (1.40).
I encounter a problem when compiling the examples using readline package.
fileman.c cannot load:
# make
cc -g -I../..  -target sun4 -c  fileman.c
cc -g -L.. -o fileman fileman.o -lreadline -ltermcap
Undefined
_xmalloc
_xrealloc
*** Error code 1
make: Fatal error: Command failed for target `fileman'

gdb loads properly, because xmalloc is defined in utils.c with a number
of other procedures for gdb use only.

xmalloc and xrealloc are they defined in newer versions of gcc library ?
If not, is it possible to extract xmalloc and xrealloc from gdb without
problem for loading fileman with ? Is there somewhere a library exporting
only xmalloc and xrealloc, to supply with -lrealine ?

Besides, as I am mailing, I can quote another problem (there must be some
silly reason explaining it), line editing does not work, even after set
editing. (I am on a SS1). I must have missed something in the
documentation ? I think I have seen in the code, though, that line
editing is set by default ??

Thank you for your help,
Vincent Lextrait
University of Nice
lextrait@essi.cerisi.fr



Newsgroups: gnu.gdb.bug
From: glenn@physics.su.oz.au (Glenn Geers)
Subject: Floating point support in gdb
Organization: School of Physics, University of Sydney, Australia
Distribution: gnu
Date: Thu, 16 Apr 1992 00:45:31 GMT

Hi,
	just a quick question. Anyone working on reinstating floating point
support? It's not available (at least) on our Sun 4 or i386's. BTW I'm
talking gdb-4.5 here.

Glenn
--
___________________________________________________________________________
Glenn Geers                       | "So when it's over, 
                                  |  we're back to people.
Department of Theoretical Physics |  Just to prove that human touch
The University of Sydney          |  can have no equal."
Sydney NSW 2006 Australia         |  - Basia Trzetrzelewska, 'Prime Time TV'
                                  |
Phone: +61 2 692-3241 (voice)     |_________________________________________
       +61 2 660-2903 (fax)       |
                                  |
glenn@physics.su.oz.au            | #include <standard_disclaimer.h>
                                  |
----------------------------------------------------------------------------

Newsgroups: gnu.gdb.bug