Hide Forgot
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
Created attachment 50 [details] Tar file to reproduce bug
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}
Jim, any clues?
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.
This works with gdb 5.0, currently in Rawhide.