Bug 8302 - Gdb crashes when trying to call a C function from C++
Summary: Gdb crashes when trying to call a C function from C++
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdb
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-01-09 00:32 UTC by Jim Nance
Modified: 2008-05-01 15:37 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2000-05-30 18:31:53 UTC


Attachments (Terms of Use)
Tar file to reproduce bug (10.01 KB, application/octet-stream)
2000-01-09 00:33 UTC, Jim Nance
no flags Details

Description Jim Nance 2000-01-09 00:32:40 UTC
I have found a bug in gdb when running under Red Hat 6.1.  If I try to
call a C function from gdb while inside a C++ function, gdb (the debugger
itself, not the program its debugging) will core dump with the following
stack trace.

I also reported this bug on gnu.gdb.bug, so if you read that group you
may be seeing it twice :-)

#0  0x805f194 in find_overload_match (arg_types=0x824c680, nargs=1,
name=0x0,
    method=0, lax=0, obj=0x0, fsym=0x88225b4, valp=0x0, symp=0xbffff7f4,
    staticp=0x0) at /usr/local/home/jlnance/src/gdb-4.18/gdb/valops.c:2652
#1  0x805a69a in evaluate_subexp_standard (expect_type=0x0, exp=0x88232f8,
    pos=0xbffff940, noside=EVAL_NORMAL)
    at /usr/local/home/jlnance/src/gdb-4.18/gdb/eval.c:924
#2  0x8058c44 in evaluate_expression (exp=0x88232f8)
    at /usr/local/home/jlnance/src/gdb-4.18/gdb/eval.c:71
#3  0x80648c2 in print_command_1 (exp=0x8176c6a "usedFun(1)", inspect=0,
    voidprint=1) at /usr/local/home/jlnance/src/gdb-4.18/gdb/printcmd.c:869
#4  0x8064a17 in print_command (exp=0x8176c6a "usedFun(1)", from_tty=0)
    at /usr/local/home/jlnance/src/gdb-4.18/gdb/printcmd.c:934

If I execute the command:

    set language c

prior to calling the C function everthing works fine.

To reproduce this problem with the attached files do:

    make
    gdb -x script

Comment 1 Jim Nance 2000-01-09 00:33:59 UTC
Created attachment 50 [details]
Tar file to reproduce bug

Comment 2 Jim Nance 2000-01-13 23:42:59 UTC
I have done a little more debugging.  It looks like the ->type
field of the symbol structure is being dereferenced and causing
the crash.  Here is where gdb is crashing:
(gdb) frame 0
#0  0x8061f11 in find_overload_match (arg_types=0x0, nargs=0, name=0x0,
    method=0, lax=0, obj=0x0, fsym=0x8a866b4, valp=0x0, symp=0xbffff784,
    staticp=0x0) at valops.c:2652
2652          nparms = method ? (TYPE_NFIELDS (fns_ptr[ix].type))
(gdb) w
2647      for (ix = 0; ix < num_fns; ix++)
2648        {
2649          int jj;
2650
2651          /* Number of parameters for current candidate */
2652 >        nparms = method ? (TYPE_NFIELDS (fns_ptr[ix].type))
2653                          : (TYPE_NFIELDS (SYMBOL_TYPE (oload_syms[ix])));
2654
2655          /* Prepare array of parameter types */
2656          parm_types = (struct type **) xmalloc (nparms * (sizeof (struct
type *)));
(gdb) p *oload_syms[ix]
$2 = {ginfo = {name = 0x81a0c60 "dbSetup", value = {ivalue = 134522324,
      block = 0x804a5d4, bytes = 0x804a5d4 "\026\bh\200\001",
      address = 134522324, chain = 0x804a5d4}, language_specific = {
      cplus_specific = {demangled_name = 0x0}, chill_specific = {
        demangled_name = 0x0}}, language = language_unknown, section = 0,
    bfd_section = 0x819b4d0}, type = 0xa5, namespace = VAR_NAMESPACE,
  aclass = 135921528, line = 42620, aux_value = {basereg = 2052},
  aliases = 0x81a2384, ranges = 0x3}

Comment 3 Cristian Gafton 2000-02-17 22:45:59 UTC
Jim, any clues?

Comment 4 Jim Nance 2000-02-20 02:55:59 UTC
I have been talking to Michael Christenson (A cygnus employee) about this bug.

He works on gdb, and knows what is going on.  I dont have his email addr

handy, but if you get in touch with him, he can tell you what he knows.

Comment 5 Trond Eivind Glomsrxd 2000-05-30 18:31:59 UTC
This works with gdb 5.0, currently in Rawhide.


Note You need to log in before you can comment on or make changes to this bug.