This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

symtab/1661: hpread.c uses uninitialized memory for c++ symtab fields


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]