Bug 11912 - C++ name lookup fails
Summary: C++ name lookup fails
Status: RESOLVED DUPLICATE of bug 8888
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: 7.1
: P2 normal
Target Milestone: 7.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-13 14:40 UTC by Andre'
Modified: 2014-05-28 19:42 UTC (History)
3 users (show)

See Also:
Host: i486-linux-gnu
Target: i486-linux-gnu
Build: i486-linux-gnu
Last reconfirmed: 2010-08-16 20:45:36


Attachments
This is a script reproducing the problem. (696 bytes, text/plain)
2010-08-13 14:41 UTC, Andre'
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andre' 2010-08-13 14:40:44 UTC
The following script (also attached to this report) produces a wrong
result for 'Type Test has no component named Object.' with gdb 7.1

------------------------------- snip ------------------------------------
#!/bin/bash

###################################################################

# Commenting out the Object() constructor and using the compiler
# generated one removes the problem.

echo 'struct Object {
    Object();
    virtual ~Object();
}; ' > object.h

echo '#include "object.h"
Object::Object() {}
Object::~Object() {}
' > object.cpp


###################################################################

# Removing the inheritance from Object removes the problem.

echo '#include "object.h"
struct Test : Object
{
    void foo();
};

void Test::foo()
{
    Object s;
    int i = 1;
};

int main()
{
    Test t;
    t.foo();
}
' > main.cpp

###################################################################

g++ -g -c object.cpp -o object.o

# Removing the intermediate shared object also brings the problem to 6.8.
g++ -g -shared object.o -o libobject.so
g++ -g main.cpp -L. -lobject -o ff
export LD_LIBRARY_PATH=.

echo -e "\n6.8:"
~/bin/gdb-6.8 --nx --quiet -ex 'file ./ff' \
    -ex 'set breakpoint pending on' -ex 'set confirm off' \
    -ex 'b main.cpp:7' \
    -ex r -ex 'ptype Object' -ex 'ptype ::Object' -ex q

echo -e "\n\n\n7.1:"
~/bin/gdb-7.1 --nx --quiet -ex 'file ./ff' \
    -ex 'set breakpoint pending on' -ex 'set confirm off' \
    -ex 'b main.cpp:7' \
    -ex r -ex 'ptype Object' -ex 'ptype ::Object' -ex q

# The broken case is 'ptype Object' with 7.1
------------------------------- snip ------------------------------------

# Output:
#   6.8:
#   Reading symbols from /tmp/ff/ff...done.
#   Breakpoint 1 at 0x80487a4: file main.cpp, line 7.
#
#   Breakpoint 1, Test::foo (this=0xbfd8fb8c) at main.cpp:8
#   8       {
#   type = class Object {
#     public:
#       Object(void);
#       ~Object(int);
#   }
#   type = class Object {
#     public:
#       Object(void);
#       ~Object(int);
#   }
#
#
#   7.1:
#   Reading symbols from /tmp/ff/ff...done.
#   Breakpoint 1 at 0x80487aa: file main.cpp, line 7.
#
#   Breakpoint 1, Test::foo (this=0xbfffeecc) at main.cpp:9
#   9           Object s;
#   Type Test has no component named Object.
#   type = struct Object {
#     public:
#       Object(void);
#       ~Object(int);
#   }
Comment 1 Andre' 2010-08-13 14:41:36 UTC
Created attachment 4929 [details]
This is a script reproducing the problem.
Comment 2 Andre' 2010-08-13 14:50:09 UTC
Problem is still present in  GNU gdb (GDB) 7.2.50.20100813-cvs
Comment 3 Andre' 2010-08-16 09:00:17 UTC
On MinGW this seems to be able to crash gdb.
Comment 4 Tom Tromey 2010-08-16 20:45:36 UTC
The bug here is that the parser treats "Object" as the
constructor's name.  If you dump the intermediate expression you'll see

this->Object

Then later, lookup_struct_elt_type fails because it considers fields
but not (I think) methods.

At the very least we should be printing the type of the constructor,
not failing.

The root of the problem here is that "ptype" accepts either types or expressions,
but we don't have a good way to always differentiate between the two.

As a workaround you can use "ptype class Object" to tell the parser that
you are asking about a type.  (I learned this today while looking at the
docs :-)
say 
Comment 5 Tom Tromey 2010-08-16 20:46:12 UTC
(In reply to comment #3)
> On MinGW this seems to be able to crash gdb.

That is surprising to me; please post more info about that.
Comment 6 Andre' 2010-08-17 10:10:34 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > On MinGW this seems to be able to crash gdb.
> 
> That is surprising to me; please post more info about that.

I don't have a debug enabled FSF gdb at hand right now (will take a while to
setup the build due to the python dependencies) but we seem to get the same
crash with Code Sourcery's gdb for Symbian:

      Program received signal SIGSEGV, Segmentation fault.
      [Switching to thread 4612.0x1368]
      0x005b0c05 in int_vasprintf (result=<value optimized out>,
          format=<value optimized out>, args=<value optimized out>)
          at .././libiberty/vasprintf.c:128
      128     .././libiberty/vasprintf.c: No such file or directory.
              in .././libiberty/vasprintf.c

      (gdb) where
      #0  0x005b0c05 in int_vasprintf (result=<value optimized out>,
          format=<value optimized out>, args=<value optimized out>)
          at .././libiberty/vasprintf.c:128
      #1  0x004065be in xstrvprintf (
          format=0x722288 "Attempt to extract a component of a value that is not
a %s.
      ", ap=0x1f7eb64 "") at utils.c:1310
      #2  0x0041cb14 in throw_it (reason=RETURN_ERROR, error=7480002,
          fmt=0xffffffff <Address 0xffffffff out of bounds>, ap=0x1f7eb64 "")
          at exceptions.c:386
      #3  0x0041cb98 in throw_verror (error=GENERIC_ERROR,
          fmt=0x722288 "Attempt to extract a component of a value that is not a
%s.",
      ap=0x1f7eb64 "") at exceptions.c:402
      #4  0x00404e34 in error (
          string=0x722288 "Attempt to extract a component of a value that is not
a %s.
      ") at utils.c:815
      #5  0x0048ec37 in value_struct_elt (argp=0x1f7ebcc, args=0x0,
          name=0x4210cb8 "staticMetaObject", static_memfuncp=0x0, err=0x0)
          at valops.c:1843
      #6  0x00508c19 in valpy_getitem (self=0x1fd3938, key=0x52ec688)
          at .././gdb/python/python-value.c:286
      #7  0x005faf82 in PyEval_EvalFrameEx (f=0x42803dc, throwflag=0)
          at Python/ceval.c:1192
      #8  0x005fe04c in PyEval_EvalCodeEx (co=0x52cb728, globals=0x1febb54,
          locals=0x0, args=0x428bcd0, argcount=2, kws=0x428bcd8, kwcount=0,
          defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
      #9  0x005fd0b4 in PyEval_EvalFrameEx (f=0x428bb24, throwflag=0)
          at Python/ceval.c:3660
      #10 0x005fe04c in PyEval_EvalCodeEx (co=0x52cb728, globals=0x1febb54,
          locals=0x0, args=0x20526e8, argcount=2, kws=0x20526f0, kwcount=0,
          defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
      #11 0x005fd0b4 in PyEval_EvalFrameEx (f=0x205253c, throwflag=0)
          at Python/ceval.c:3660
      #12 0x005fe04c in PyEval_EvalCodeEx (co=0x412dec0, globals=0x1febb54,
          locals=0x0, args=0x412cf78, argcount=2, kws=0x0, kwcount=0, defs=0x0,
          defcount=0, closure=0x0) at Python/ceval.c:2831
      #13 0x006490a6 in function_call (func=0x52dea04, arg=0x412cf6c, kw=0x0)
          at Objects/funcobject.c:517
      #14 0x005da76f in PyObject_Call (func=0x7222c2, arg=0x412cf6c, kw=0x0)
          at Objects/abstract.c:1860
      #15 0x006387a6 in instancemethod_call (func=0x52dea04, arg=0x412456c, kw=0x0)
          at Objects/classobject.c:2497
      #16 0x005da76f in PyObject_Call (func=0x7222c2, arg=0x412456c, kw=0x0)
          at Objects/abstract.c:1860
      #17 0x005f786b in PyEval_CallObjectWithKeywords (func=0x4178414,
          arg=0x412456c, kw=0x0) at Python/ceval.c:3433
      #18 0x0063a282 in PyInstance_New (klass=0x52cffbc, arg=0x412456c, kw=0x0)
          at Objects/classobject.c:560
      #19 0x005da76f in PyObject_Call (func=0x7222c2, arg=0x412456c, kw=0x0)
          at Objects/abstract.c:1860
      #20 0x005fc388 in PyEval_EvalFrameEx (f=0x4f92fa4, throwflag=0)
          at Python/ceval.c:3775
      #21 0x005fe04c in PyEval_EvalCodeEx (co=0x412dd58, globals=0x1febb54,
          locals=0x0, args=0x5320c1c, argcount=1, kws=0x5320c20, kwcount=0,
          defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
      #22 0x005fd0b4 in PyEval_EvalFrameEx (f=0x5320acc, throwflag=0)
          at Python/ceval.c:3660
      #23 0x005fe04c in PyEval_EvalCodeEx (co=0x412dcc8, globals=0x1febb54,
          locals=0x0, args=0x41236f0, argcount=3, kws=0x0, kwcount=0, defs=0x0,
          defcount=0, closure=0x0) at Python/ceval.c:2831
      #24 0x006490a6 in function_call (func=0x52de924, arg=0x41236e4, kw=0x0)
          at Objects/funcobject.c:517
      #25 0x005da76f in PyObject_Call (func=0x7222c2, arg=0x41236e4, kw=0x0)
          at Objects/abstract.c:1860
      #26 0x006387a6 in instancemethod_call (func=0x52de924, arg=0x412c46c, kw=0x0)
          at Objects/classobject.c:2497
      #27 0x005dd6b8 in PyObject_CallMethodObjArgs (callable=<value optimized out>,
          name=0x4120f60) at Objects/abstract.c:1860
      #28 0x0053ed58 in cmdpy_function (command=0x4143ff8,
          args=0x1f7fa83 "options:fancy vars: expanded:local.s typeformats:
formats: watchers:", from_tty=1) at .././gdb/python/python-cmd.c:144
      #29 0x00403e7e in execute_command (p=0x1f7fac6 ":", from_tty=1) at top.c:442
      #30 0x0041cf36 in catch_exception (uiout=0x1fd1a18,
          func=0x5054e8 <do_captured_execute_command>, func_args=0x1f7fb08, mask=6)
          at exceptions.c:462
      #31 0x00505497 in cli_interpreter_exec (data=0x0,
          command_str=<value optimized out>) at .././gdb/cli/cli-interp.c:130
      #32 0x0041625e in interp_exec (interp=0x1fbff00,
          command_str=0x1fa35e8 "bb options:fancy vars: expanded:local.s
typeformats:
      formats: watchers:") at interps.c:326
      #33 0x00506d8e in mi_cmd_interpreter_exec (
          command=0x76124d "-interpreter-exec", argv=0x1f7fbe4, argc=2)
          at .././gdb/mi/mi-interp.c:206
      #34 0x00538f2f in captured_mi_execute_command (uiout=0x1fd2830,
          data=0x1fc8020) at .././gdb/mi/mi-main.c:1226
      #35 0x0041cf36 in catch_exception (uiout=0x1fd2830,
          func=0x538d0c <captured_mi_execute_command>, func_args=0x1fc8020, mask=6)
          at exceptions.c:462
      #36 0x00538a68 in mi_execute_command (
          cmd=0x4145908 "65bb options:fancy vars: expanded:local.s typeformats:
formats: watchers:", from_tty=1) at .././gdb/mi/mi-main.c:1282
      #37 0x0050641a in mi_execute_command_wrapper (
          cmd=0x4145908 "65bb options:fancy vars: expanded:local.s typeformats:
formats: watchers:") at .././gdb/mi/mi-interp.c:251
      #38 0x0043ce6c in handle_file_event (data={ptr = 0x0, integer = 0})
          at event-loop.c:812
      #39 0x0043c514 in process_event () at event-loop.c:394
      #40 0x0043cde9 in gdb_do_one_event (data=0x0) at event-loop.c:459
      #41 0x0041cd4f in catch_errors (func=0x43cbd0 <gdb_do_one_event>,
          func_args=0x0, errstring=0x703f98 "", mask=6) at exceptions.c:510
      #42 0x0043c9c4 in start_event_loop () at event-loop.c:483
      #43 0x004025cb in captured_command_loop (data=0x0) at .././gdb/main.c:231
      #44 0x0041cd4f in catch_errors (func=0x4025c0 <captured_command_loop>,
          func_args=0x0, errstring=0x6f1080 "", mask=6) at exceptions.c:510
      #45 0x00402348 in captured_main (data=0x1f7ff30) at .././gdb/main.c:1007
      #46 0x0041cd4f in catch_errors (func=0x4015f0 <captured_main>,
          func_args=0x1f7ff30, errstring=0x6f1080 "", mask=6) at exceptions.c:510
      #47 0x00401426 in gdb_main (args=0x1f7ff30) at .././gdb/main.c:1016
      #48 0x004013e8 in main (argc=4, argv=0x392480) at gdb.c:33
Comment 7 Andre' 2010-08-17 10:21:38 UTC
(In reply to comment #4)
> [...]
> As a workaround you can use "ptype class Object" to tell the parser that
> you are asking about a type.  (I learned this today while looking at the
> docs :-)

Thanks for the workaround. With

 type = gdb.parse_and_eval("(class '%s'*)0" % typename).type.target()

it's even usable with python ;-)
Comment 8 Andre' 2010-08-17 10:46:21 UTC
(In reply to comment #6)
>       Program received signal SIGSEGV, Segmentation fault.

By now I think this is unrelated, it only happens to be triggered by the same
"user" code using the name lookups. So when that was enabled/disabled also this
crash occurs.
Comment 9 Marc Khouzam 2010-09-09 15:08:42 UTC
I've also seen what seems like the same problem in the following example.  Note
that this also fails for GDB 6.8

class bar{};
class foo : public bar {
  public:
    foo() {}  // Comment this line to make things work
    void test() { return; }
};

int main(void) {
    foo f; f.test();
    return 0;
}

//commands to execute in GDB, which will make the last one fail
//b foo::test
//r
//p (*(bar*) this)

The print will cause GDB to report a syntax error.
Removing the constructor of foo fixes the problem.
Adding 'struct' or 'class', as in 'p (*(struct bar*) this)' also fixes the problem.

Comment 10 cvs-commit@gcc.gnu.org 2011-08-26 12:30:48 UTC
CVSROOT:	/cvs/src
Module name:	src
Branch: 	gdb_7_3-branch
Changes by:	marckhouzam@sourceware.org	2011-08-26 12:30:43

Modified files:
	gdb/testsuite/gdb.mi: mi-var-cp.cc 
	gdb            : ChangeLog varobj.c 
	gdb/testsuite  : ChangeLog 
Added files:
	gdb/testsuite/gdb.mi: mi-inheritance-syntax-error.cc 
	                      mi-inheritance-syntax-error.exp 

Log message:
	2011-08-26  Marc Khouzam  <marc.khouzam@ericsson.com>
	
	PR mi/11912
	* varobj.c (cplus_describe_child): Add the keyword
	'class' to the output of the method when dealing
	with a cast to a base class.
	
	2011-08-26  Marc Khouzam  <marc.khouzam@ericsson.com>
	
	PR mi/11912
	* gdb.mi/mi-inheritance-syntax-error.cc: New file.
	* gdb.mi/mi-inheritance-syntax-error.exp: New file.
	* gdb.mi/mi-var-cp.cc: Updated for new 'class'
	keyword in output of -var-info-path-expression.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/mi-inheritance-syntax-error.cc.diff?cvsroot=src&only_with_tag=gdb_7_3-branch&r1=NONE&r2=1.1.2.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/mi-inheritance-syntax-error.exp.diff?cvsroot=src&only_with_tag=gdb_7_3-branch&r1=NONE&r2=1.1.2.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/mi-var-cp.cc.diff?cvsroot=src&only_with_tag=gdb_7_3-branch&r1=1.13&r2=1.13.2.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&only_with_tag=gdb_7_3-branch&r1=1.12887.2.67&r2=1.12887.2.68
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/varobj.c.diff?cvsroot=src&only_with_tag=gdb_7_3-branch&r1=1.176.2.1&r2=1.176.2.2
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&only_with_tag=gdb_7_3-branch&r1=1.2655.2.28&r2=1.2655.2.29
Comment 11 cvs-commit@gcc.gnu.org 2011-08-26 12:33:04 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	marckhouzam@sourceware.org	2011-08-26 12:33:00

Modified files:
	gdb/testsuite/gdb.mi: mi-var-cp.cc 
	gdb            : ChangeLog varobj.c 
	gdb/testsuite  : ChangeLog 
Added files:
	gdb/testsuite/gdb.mi: mi-inheritance-syntax-error.cc 
	                      mi-inheritance-syntax-error.exp 

Log message:
	2011-08-26  Marc Khouzam  <marc.khouzam@ericsson.com>
	
	PR mi/11912
	* varobj.c (cplus_describe_child): Add the keyword
	'class' to the output of the method when dealing
	with a cast to a base class.
	
	2011-08-26  Marc Khouzam  <marc.khouzam@ericsson.com>
	
	PR mi/11912
	* gdb.mi/mi-inheritance-syntax-error.cc: New file.
	* gdb.mi/mi-inheritance-syntax-error.exp: New file.
	* gdb.mi/mi-var-cp.cc: Updated for new 'class'
	keyword in output of -var-info-path-expression.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/mi-inheritance-syntax-error.cc.diff?cvsroot=src&r1=1.1&r2=1.2
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/mi-inheritance-syntax-error.exp.diff?cvsroot=src&r1=1.1&r2=1.2
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.mi/mi-var-cp.cc.diff?cvsroot=src&r1=1.13&r2=1.14
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.13279&r2=1.13280
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/varobj.c.diff?cvsroot=src&r1=1.181&r2=1.182
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2838&r2=1.2839
Comment 12 Andre' 2011-08-26 14:41:35 UTC
Is this really a step into the right direction? Isn't the problem rather on the "input" side? I think the user should not be required to use 'struct foo' or 'class foo' when just using 'foo' is correct C++.
Comment 13 Marc Khouzam 2011-08-26 15:38:01 UTC
(In reply to comment #12)
> Is this really a step into the right direction? Isn't the problem rather on the
> "input" side? I think the user should not be required to use 'struct foo' or
> 'class foo' when just using 'foo' is correct C++.

I agree with you.  However, I did not know how to fix the C++ parser to accept 'foo'.

The fix I committed does not solve this PR, but solves a side-effect that would cause the frontend to get a syntax error using an expression that GDB said to use.  For details, please see:

http://sourceware.org/ml/gdb-patches/2010-09/msg00204.html
Comment 14 Tom Tromey 2012-12-14 19:25:05 UTC
I think this is a dup.

*** This bug has been marked as a duplicate of bug 8888 ***
Comment 15 Jackie Rosen 2014-02-16 17:44:51 UTC Comment hidden (spam)