Home » Language IDEs » C / C++ IDE (CDT) » Cannot debug if main has argument support code
| Cannot debug if main has argument support code [message #155129] |
Tue, 27 September 2005 12:31  |
Eclipse User |
|
|
|
Hi folks,
If you attempted to debug a problem with main that supports
arguments, you may run into a problem:
#include <iostream>
using namespace std;
int main(int argc, char* argv[]) { // <=Place breakpoint here (Hit F6
for(int i=0; i<argc; i++) // and error appears
cout << argv[i] << endl;
}
Here is what I got for errors!
===================================
mi_cmd_stack_list_frames: No stack.
No symbol "argc" in current context.
mi_cmd_var_create: unable to create variable object
No symbol "argv" in current context.
mi_cmd_var_create: unable to create variable object
No symbol "argc" in current context.
===================================
Dan
|
|
|
| Re: Cannot debug if main has argument support code [message #155161 is a reply to message #155129] |
Tue, 27 September 2005 13:32  |
| Eclipse User |
|
|
|
Sorry, I forgot to include some details...
I am running Eclipse with this environment:
1) Windows 2k Pro
2) Eclipse 3.1 (WTP "all" bundle)
3) CDT 3.0
4) Recently downloaded and installed, CygWin, w/ gdb
(gdb 6.3.50_2004-12-28-cvs (cygwin-special))
Note: this is what I found as the "latest" Cygwin build and
seems that gdb is almost a year old? Hmmmm..
I forgot to mention that in debug mode, there was a reference
to the 'alloca' function and also that you cannot continue to debug
your code and it stops dead in it's tracks. Ugh...
Note: I ran this simple code manually in the Cygwin window and
was able to complile and debug, adding arguments to the program,
and single stepping through, the line by line with the 'next' and it runs
just fine. I see all the arguments printed out to the console and it works.
HOWEVER! If instead of using the 'next' gdb command and stepping
though with the 'step' gdb command, I noticed in places where there might
be a problem to CDT? See where it says in the following gdb output where
alloca repeatedly appears.... (I noticed this only because CDT reported a
break somewhere in the alloca region)
....
0x0043d382 in std::endl<char, std::char_traits<char> > ()
(gdb) s
Single stepping until exit from function _ZSt4endlIcSt11char_traitsIcEER
St13basic_ostreamIT_T0_ES6_,
which has no line number information.
0x0042b1d6 in std::ostream::put ()
at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77
77 static ios_base::Init __ioinit;
(gdb) s
0x6109dbe0 in pthread_getspecific () from /usr/bin/cygwin1.dll
(gdb) s
Single stepping until exit from function pthread_getspecific,
which has no line number information.
0x6109d010 in cygwin1!__getreent () from /usr/bin/cygwin1.dll
(gdb) s
Single stepping until exit from function cygwin1!__getreent,
which has no line number information.
0x610e0bb0 in cygwin1!_alloca () from /usr/bin/cygwin1.dll
(gdb) s
Single stepping until exit from function cygwin1!_alloca,
which has no line number information.
0x7c597e53 in KERNEL32!IsBadWritePtr ()
from /cygdrive/c/WINNT/system32/KERNEL32.DLL
(gdb)
I suspect that perhaps CDT is using the 'step' gdb command instead
of the 'next' gdb command - unless you think otherwise...
Dan
"Dan Thurman" <dant@cdkkt.com> wrote in message
news:dhbs66$4n4$1@news.eclipse.org...
> Hi folks,
>
> If you attempted to debug a problem with main that supports
> arguments, you may run into a problem:
>
> #include <iostream>
> using namespace std;
>
> int main(int argc, char* argv[]) { // <=Place breakpoint here (Hit F6
> for(int i=0; i<argc; i++) // and error appears
> cout << argv[i] << endl;
> }
>
>
> Here is what I got for errors!
>
> ===================================
> mi_cmd_stack_list_frames: No stack.
> No symbol "argc" in current context.
> mi_cmd_var_create: unable to create variable object
> No symbol "argv" in current context.
> mi_cmd_var_create: unable to create variable object
> No symbol "argc" in current context.
> ===================================
>
> Dan
>
>
|
|
| |
| Re: Cannot debug if main has argument support code [message #155192 is a reply to message #155161] |
Tue, 27 September 2005 16:38 |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
CDT doesn't use "step" instead of "next". Please, provide a test case and
description on how to reproduce it.
"Dan Thurman" <dant@cdkkt.com> wrote in message
news:dhbvns$agm$1@news.eclipse.org...
> Sorry, I forgot to include some details...
>
> I am running Eclipse with this environment:
>
> 1) Windows 2k Pro
> 2) Eclipse 3.1 (WTP "all" bundle)
> 3) CDT 3.0
> 4) Recently downloaded and installed, CygWin, w/ gdb
> (gdb 6.3.50_2004-12-28-cvs (cygwin-special))
> Note: this is what I found as the "latest" Cygwin build and
> seems that gdb is almost a year old? Hmmmm..
>
> I forgot to mention that in debug mode, there was a reference
> to the 'alloca' function and also that you cannot continue to debug
> your code and it stops dead in it's tracks. Ugh...
>
> Note: I ran this simple code manually in the Cygwin window and
> was able to complile and debug, adding arguments to the program,
> and single stepping through, the line by line with the 'next' and it runs
> just fine. I see all the arguments printed out to the console and it
> works.
> HOWEVER! If instead of using the 'next' gdb command and stepping
> though with the 'step' gdb command, I noticed in places where there might
> be a problem to CDT? See where it says in the following gdb output where
> alloca repeatedly appears.... (I noticed this only because CDT reported a
> break somewhere in the alloca region)
>
> ...
> 0x0043d382 in std::endl<char, std::char_traits<char> > ()
> (gdb) s
> Single stepping until exit from function _ZSt4endlIcSt11char_traitsIcEER
> St13basic_ostreamIT_T0_ES6_,
> which has no line number information.
> 0x0042b1d6 in std::ostream::put ()
> at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77
> 77 static ios_base::Init __ioinit;
> (gdb) s
> 0x6109dbe0 in pthread_getspecific () from /usr/bin/cygwin1.dll
> (gdb) s
> Single stepping until exit from function pthread_getspecific,
> which has no line number information.
> 0x6109d010 in cygwin1!__getreent () from /usr/bin/cygwin1.dll
> (gdb) s
> Single stepping until exit from function cygwin1!__getreent,
> which has no line number information.
> 0x610e0bb0 in cygwin1!_alloca () from /usr/bin/cygwin1.dll
> (gdb) s
> Single stepping until exit from function cygwin1!_alloca,
> which has no line number information.
> 0x7c597e53 in KERNEL32!IsBadWritePtr ()
> from /cygdrive/c/WINNT/system32/KERNEL32.DLL
> (gdb)
>
> I suspect that perhaps CDT is using the 'step' gdb command instead
> of the 'next' gdb command - unless you think otherwise...
>
> Dan
>
> "Dan Thurman" <dant@cdkkt.com> wrote in message
> news:dhbs66$4n4$1@news.eclipse.org...
>> Hi folks,
>>
>> If you attempted to debug a problem with main that supports
>> arguments, you may run into a problem:
>>
>> #include <iostream>
>> using namespace std;
>>
>> int main(int argc, char* argv[]) { // <=Place breakpoint here (Hit F6
>> for(int i=0; i<argc; i++) // and error appears
>> cout << argv[i] << endl;
>> }
>>
>>
>> Here is what I got for errors!
>>
>> ===================================
>> mi_cmd_stack_list_frames: No stack.
>> No symbol "argc" in current context.
>> mi_cmd_var_create: unable to create variable object
>> No symbol "argv" in current context.
>> mi_cmd_var_create: unable to create variable object
>> No symbol "argc" in current context.
>> ===================================
>>
>> Dan
>>
>>
>
>
|
|
|
| Re: Cannot debug if main has argument support code [message #155199 is a reply to message #155192] |
Tue, 27 September 2005 18:36 |
| Eclipse User |
|
|
|
Code:
==================
1: #include <iostream>
2: using namespace std;
3:
4: int main(int argc, char* argv[]) {
5: for(int i=0; i<argc; i++)
6: cout << argv[i] << endl;
7: }
Setup:
==================
Breakpoint set on line #4
Added 3 arguments: foo goo hoo
Started debug after building:
==================
1) In debug mode, the breakpoint stopped in main() with:
Cygwin GDB Debugger (9/27/05 3:04 PM) (Suspended)
Thread [1] (Suspended: Breakpoint hit.)
1 main() at ..\playing.cpp:4
Thread [2] (Suspended)
7 <symbol is not available>
6 ReadFile()
5 sigemptyset()
4 toascii()
3 toascii()
2 toascii()
1 <symbol is not available>
2) Moving the mouse cursor over "int" in string: "int argc", and
hovering displayed (red color) in console (NO MOUSE CLICK!)
++++++++++++++++++++++++++++++++
mi_cmd_stack_list_frames: No stack.
Attempt to use a type name as an expression
++++++++++++++++++++++++++++++++
Moving mouse cursor from "int" to "char" in string: "char* argv[]" and
hovering, displayed (in red) another line to console output:
++++++++++++++++++++++++++++++++
Attempt to use a type name as an expression
++++++++++++++++++++++++++++++++
3) Pressing the F6 (step over) function key revealed:
Cygwin GDB Debugger (9/27/05 3:05 PM) (Suspended)
Thread [1] (Suspended)
2 _alloca() at \usr\lib\gcc\i686-pc-cygwin\3.4.4\include\c++\iostream:77
1 main() at ..\playing.cpp:4
Thread [2] (Suspended)
7 <symbol is not available>
6 ReadFile()
5 sigemptyset()
4 toascii()
3 toascii()
2 toascii()
1 <symbol is not available>
A NEW tab pane appears in the editor panel with this information:
TAB: 2_alloca() at iostream:77
==================================
Source not found.
[Edit Source Lookup path...] <= button
==================================
Please note above thread #1, 2! Debugger stopped at _alloca() above in
the
thread! I expected the debugger to stop at line: #5 of my cpp code!
If you keep hitting the F6 key, it acts like a 'step' gdb command. I have
to
keep hitting this function key several times before I can get to line #5
as I
had initially expected!
I have explained as before that in using 'step' gdb command within the
cygwin
shell, I can see the the step(s) command and it appears almost exactly
like what
CDT is doing, EXCEPT - that it STARTS on the first _alloca() call it
encounters.
Somehow, this is causing a problem with CDT in debug mode.
I posted previously, my environment: Windows 2000 Professional, w/ Cygwin
(latest) installed and Eclipse 3.1 w/ WTP "all-in-one" bundle and of course
CDT
3.0. I cannot get any simpler than this.
Dan
"Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
news:dhcaki$qtd$1@news.eclipse.org...
> CDT doesn't use "step" instead of "next". Please, provide a test case and
> description on how to reproduce it.
>
> "Dan Thurman" <dant@cdkkt.com> wrote in message
> news:dhbvns$agm$1@news.eclipse.org...
> > Sorry, I forgot to include some details...
> >
> > I am running Eclipse with this environment:
> >
> > 1) Windows 2k Pro
> > 2) Eclipse 3.1 (WTP "all" bundle)
> > 3) CDT 3.0
> > 4) Recently downloaded and installed, CygWin, w/ gdb
> > (gdb 6.3.50_2004-12-28-cvs (cygwin-special))
> > Note: this is what I found as the "latest" Cygwin build and
> > seems that gdb is almost a year old? Hmmmm..
> >
> > I forgot to mention that in debug mode, there was a reference
> > to the 'alloca' function and also that you cannot continue to debug
> > your code and it stops dead in it's tracks. Ugh...
> >
> > Note: I ran this simple code manually in the Cygwin window and
> > was able to complile and debug, adding arguments to the program,
> > and single stepping through, the line by line with the 'next' and it
runs
> > just fine. I see all the arguments printed out to the console and it
> > works.
> > HOWEVER! If instead of using the 'next' gdb command and stepping
> > though with the 'step' gdb command, I noticed in places where there
might
> > be a problem to CDT? See where it says in the following gdb output
where
> > alloca repeatedly appears.... (I noticed this only because CDT reported
a
> > break somewhere in the alloca region)
> >
> > ...
> > 0x0043d382 in std::endl<char, std::char_traits<char> > ()
> > (gdb) s
> > Single stepping until exit from function _ZSt4endlIcSt11char_traitsIcEER
> > St13basic_ostreamIT_T0_ES6_,
> > which has no line number information.
> > 0x0042b1d6 in std::ostream::put ()
> > at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77
> > 77 static ios_base::Init __ioinit;
> > (gdb) s
> > 0x6109dbe0 in pthread_getspecific () from /usr/bin/cygwin1.dll
> > (gdb) s
> > Single stepping until exit from function pthread_getspecific,
> > which has no line number information.
> > 0x6109d010 in cygwin1!__getreent () from /usr/bin/cygwin1.dll
> > (gdb) s
> > Single stepping until exit from function cygwin1!__getreent,
> > which has no line number information.
> > 0x610e0bb0 in cygwin1!_alloca () from /usr/bin/cygwin1.dll
> > (gdb) s
> > Single stepping until exit from function cygwin1!_alloca,
> > which has no line number information.
> > 0x7c597e53 in KERNEL32!IsBadWritePtr ()
> > from /cygdrive/c/WINNT/system32/KERNEL32.DLL
> > (gdb)
> >
> > I suspect that perhaps CDT is using the 'step' gdb command instead
> > of the 'next' gdb command - unless you think otherwise...
> >
> > Dan
> >
> > "Dan Thurman" <dant@cdkkt.com> wrote in message
> > news:dhbs66$4n4$1@news.eclipse.org...
> >> Hi folks,
> >>
> >> If you attempted to debug a problem with main that supports
> >> arguments, you may run into a problem:
> >>
> >> #include <iostream>
> >> using namespace std;
> >>
> >> int main(int argc, char* argv[]) { // <=Place breakpoint here (Hit F6
> >> for(int i=0; i<argc; i++) // and error appears
> >> cout << argv[i] << endl;
> >> }
> >>
> >>
> >> Here is what I got for errors!
> >>
> >> ===================================
> >> mi_cmd_stack_list_frames: No stack.
> >> No symbol "argc" in current context.
> >> mi_cmd_var_create: unable to create variable object
> >> No symbol "argv" in current context.
> >> mi_cmd_var_create: unable to create variable object
> >> No symbol "argc" in current context.
> >> ===================================
> >>
> >> Dan
> >>
> >>
> >
> >
>
>
|
|
|
| Re: Cannot debug if main has argument support code [message #155420 is a reply to message #155199] |
Thu, 29 September 2005 14:06 |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
The first two problems are NOT errors. When you are hovering over a text in
the editor CDT tries to evaluate the text by sending an evaluation command
to gdb. If the expression presented by the text is not in the scope or it is
a keyword the evaluation fails. Unfortunately, we are unable to filter some
gdb messages.
Regarding the third problem, I've tried your code on my Windows machine and
it works fine. When I press F6, the debugger steps over the "main" function
and the program exits.
If you want to see what kind of commands the CDT debugger sends to gdb get
the gdb trace. On how to do it see the CDT debugger FAQ #5.
"Dan Thurman" <dant@cdkkt.com> wrote in message
news:dhchhk$4es$1@news.eclipse.org...
> Code:
> ==================
> 1: #include <iostream>
> 2: using namespace std;
> 3:
> 4: int main(int argc, char* argv[]) {
> 5: for(int i=0; i<argc; i++)
> 6: cout << argv[i] << endl;
> 7: }
>
> Setup:
> ==================
> Breakpoint set on line #4
> Added 3 arguments: foo goo hoo
>
> Started debug after building:
> ==================
> 1) In debug mode, the breakpoint stopped in main() with:
>
> Cygwin GDB Debugger (9/27/05 3:04 PM) (Suspended)
> Thread [1] (Suspended: Breakpoint hit.)
> 1 main() at ..\playing.cpp:4
> Thread [2] (Suspended)
> 7 <symbol is not available>
> 6 ReadFile()
> 5 sigemptyset()
> 4 toascii()
> 3 toascii()
> 2 toascii()
> 1 <symbol is not available>
>
> 2) Moving the mouse cursor over "int" in string: "int argc", and
> hovering displayed (red color) in console (NO MOUSE CLICK!)
> ++++++++++++++++++++++++++++++++
> mi_cmd_stack_list_frames: No stack.
> Attempt to use a type name as an expression
> ++++++++++++++++++++++++++++++++
>
> Moving mouse cursor from "int" to "char" in string: "char* argv[]" and
> hovering, displayed (in red) another line to console output:
>
> ++++++++++++++++++++++++++++++++
> Attempt to use a type name as an expression
> ++++++++++++++++++++++++++++++++
>
> 3) Pressing the F6 (step over) function key revealed:
>
> Cygwin GDB Debugger (9/27/05 3:05 PM) (Suspended)
> Thread [1] (Suspended)
> 2 _alloca() at \usr\lib\gcc\i686-pc-cygwin\3.4.4\include\c++\iostream:77
> 1 main() at ..\playing.cpp:4
> Thread [2] (Suspended)
> 7 <symbol is not available>
> 6 ReadFile()
> 5 sigemptyset()
> 4 toascii()
> 3 toascii()
> 2 toascii()
> 1 <symbol is not available>
>
> A NEW tab pane appears in the editor panel with this information:
>
> TAB: 2_alloca() at iostream:77
> ==================================
> Source not found.
> [Edit Source Lookup path...] <= button
> ==================================
>
> Please note above thread #1, 2! Debugger stopped at _alloca() above in
> the
> thread! I expected the debugger to stop at line: #5 of my cpp code!
>
> If you keep hitting the F6 key, it acts like a 'step' gdb command. I
> have
> to
> keep hitting this function key several times before I can get to line #5
> as I
> had initially expected!
>
> I have explained as before that in using 'step' gdb command within the
> cygwin
> shell, I can see the the step(s) command and it appears almost exactly
> like what
> CDT is doing, EXCEPT - that it STARTS on the first _alloca() call it
> encounters.
> Somehow, this is causing a problem with CDT in debug mode.
>
> I posted previously, my environment: Windows 2000 Professional, w/ Cygwin
> (latest) installed and Eclipse 3.1 w/ WTP "all-in-one" bundle and of
> course
> CDT
> 3.0. I cannot get any simpler than this.
>
> Dan
>
> "Mikhail Khodjaiants" <mikhailk@qnx.com> wrote in message
> news:dhcaki$qtd$1@news.eclipse.org...
>> CDT doesn't use "step" instead of "next". Please, provide a test case and
>> description on how to reproduce it.
>>
>> "Dan Thurman" <dant@cdkkt.com> wrote in message
>> news:dhbvns$agm$1@news.eclipse.org...
>> > Sorry, I forgot to include some details...
>> >
>> > I am running Eclipse with this environment:
>> >
>> > 1) Windows 2k Pro
>> > 2) Eclipse 3.1 (WTP "all" bundle)
>> > 3) CDT 3.0
>> > 4) Recently downloaded and installed, CygWin, w/ gdb
>> > (gdb 6.3.50_2004-12-28-cvs (cygwin-special))
>> > Note: this is what I found as the "latest" Cygwin build and
>> > seems that gdb is almost a year old? Hmmmm..
>> >
>> > I forgot to mention that in debug mode, there was a reference
>> > to the 'alloca' function and also that you cannot continue to debug
>> > your code and it stops dead in it's tracks. Ugh...
>> >
>> > Note: I ran this simple code manually in the Cygwin window and
>> > was able to complile and debug, adding arguments to the program,
>> > and single stepping through, the line by line with the 'next' and it
> runs
>> > just fine. I see all the arguments printed out to the console and it
>> > works.
>> > HOWEVER! If instead of using the 'next' gdb command and stepping
>> > though with the 'step' gdb command, I noticed in places where there
> might
>> > be a problem to CDT? See where it says in the following gdb output
> where
>> > alloca repeatedly appears.... (I noticed this only because CDT reported
> a
>> > break somewhere in the alloca region)
>> >
>> > ...
>> > 0x0043d382 in std::endl<char, std::char_traits<char> > ()
>> > (gdb) s
>> > Single stepping until exit from function
>> > _ZSt4endlIcSt11char_traitsIcEER
>> > St13basic_ostreamIT_T0_ES6_,
>> > which has no line number information.
>> > 0x0042b1d6 in std::ostream::put ()
>> > at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77
>> > 77 static ios_base::Init __ioinit;
>> > (gdb) s
>> > 0x6109dbe0 in pthread_getspecific () from /usr/bin/cygwin1.dll
>> > (gdb) s
>> > Single stepping until exit from function pthread_getspecific,
>> > which has no line number information.
>> > 0x6109d010 in cygwin1!__getreent () from /usr/bin/cygwin1.dll
>> > (gdb) s
>> > Single stepping until exit from function cygwin1!__getreent,
>> > which has no line number information.
>> > 0x610e0bb0 in cygwin1!_alloca () from /usr/bin/cygwin1.dll
>> > (gdb) s
>> > Single stepping until exit from function cygwin1!_alloca,
>> > which has no line number information.
>> > 0x7c597e53 in KERNEL32!IsBadWritePtr ()
>> > from /cygdrive/c/WINNT/system32/KERNEL32.DLL
>> > (gdb)
>> >
>> > I suspect that perhaps CDT is using the 'step' gdb command instead
>> > of the 'next' gdb command - unless you think otherwise...
>> >
>> > Dan
>> >
>> > "Dan Thurman" <dant@cdkkt.com> wrote in message
>> > news:dhbs66$4n4$1@news.eclipse.org...
>> >> Hi folks,
>> >>
>> >> If you attempted to debug a problem with main that supports
>> >> arguments, you may run into a problem:
>> >>
>> >> #include <iostream>
>> >> using namespace std;
>> >>
>> >> int main(int argc, char* argv[]) { // <=Place breakpoint here (Hit
>> >> F6
>> >> for(int i=0; i<argc; i++) // and error appears
>> >> cout << argv[i] << endl;
>> >> }
>> >>
>> >>
>> >> Here is what I got for errors!
>> >>
>> >> ===================================
>> >> mi_cmd_stack_list_frames: No stack.
>> >> No symbol "argc" in current context.
>> >> mi_cmd_var_create: unable to create variable object
>> >> No symbol "argv" in current context.
>> >> mi_cmd_var_create: unable to create variable object
>> >> No symbol "argc" in current context.
>> >> ===================================
>> >>
>> >> Dan
>> >>
>> >>
>> >
>> >
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Mon May 12 17:53:17 EDT 2025
Powered by FUDForum. Page generated in 0.02747 seconds |
Home