This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
symtab/1661: hpread.c uses uninitialized memory for c++ symtab fields
- From: mec dot gnu at mindspring dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 31 May 2004 01:58:46 -0000
- Subject: symtab/1661: hpread.c uses uninitialized memory for c++ symtab fields
- Reply-to: mec dot gnu at mindspring dot com
>Number: 1661
>Category: symtab
>Synopsis: hpread.c uses uninitialized memory for c++ symtab fields
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon May 31 02:08:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: mec.gnu@mindspring.com
>Release: gdb 6.1
>Organization:
>Environment:
native hppa2.0w-hp-hpux11.11
hp acc A.03.45
>Description:
I noticed a funny regression in gdb.cp/from gdb 6.1 to gdb gdb_6_1-branch 2004-05-25.
# gdb 6.1
(gdb) ptype class Base1
type = class Base1 {
public:
int x;
Base1(int);
}
# gdb gdb_6_1-branch 2004-05-25
(gdb) ptype class Base1
type = class Base1
type = class Base1 {
public:
int x;
}
The bug is that "Base1(int)" disappeared between gdb 6.1 and the branch.
This is weird because there's nothing on the branch that touches hp acCC support.
It turns out that c_type_print_base checks a flag to decide whether to print a C++ method:
for (j = 0; j < len2; j++)
if (!TYPE_FN_FIELD_ARTIFICIAL (f, j))
real_len++;
...
/* Do not print out artificial methods. */
if (TYPE_FN_FIELD_ARTIFICIAL (f, j))
continue;
And hpread.c never initializes TYPE_FN_FIELD_ARTIFICIAL. On top of that, hpread.c uses uninitialized alloca'd memory for the c++ field memory.
/* hpread_read_struct_type */
/* If no such method was found, allocate a new entry in the list */
if (!fn_p)
{
/* Get space to record this member function */
/* Note: alloca used; this will disappear on routine exit */
fn_new = (struct next_fn_field *) alloca (sizeof (struct next_fn_field));
fn_new->next = fn_list;
fn_list = fn_new;
So, the is_artificial bit -- as well as other data members of the field structure -- is usually 0 but occasionally gets set to a non-zero value.
>How-To-Repeat:
Run gdb.cp classes.exp a lot. I don't know how many times qualifies as "a lot".
>Fix:
memset the memory to zero after alloca'ing it.
>Release-Note:
>Audit-Trail:
>Unformatted: