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); # }
Created attachment 4929 [details] This is a script reproducing the problem.
Problem is still present in GNU gdb (GDB) 7.2.50.20100813-cvs
On MinGW this seems to be able to crash gdb.
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
(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.
(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
(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 ;-)
(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.
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.
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
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
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++.
(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
I think this is a dup. *** This bug has been marked as a duplicate of bug 8888 ***
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.