SETTING PROGRAMS ARGUMENTS IN DEBUG MODE CAUSES "FREEZE"

[nickrt]

Hello

I am using 8.02, windows, mingw (gcc) version, simple terminal application.

When I set Project->Set Programs' Arguments, to include the '\' character, as in: "-a e:\test\" and then Debug->Start, the debugger does not seem to run, the window shows:

Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.7.50.20071127

and no terminal window is shown and there is no way to exit except to close Code:Blocks.

This does not happen if the '\' is not present in the program arguments, nor does it happen if I just run use Build->Run.

There seems to be something odd about using the debugger and passing my main() with arguments that have '\'??

Can anyone help?

N

[ollydbg]

This is a common mistake made by beginners.
You should use '\\' instead of '\' .

[nickrt]

I agree this is a common mistake made by beginners!

I have been programming since 1979 so not exactly a beginner!

When passing arguments to the program from the command line, you do not use '\\' since the DOS command line processor does not interpret the '\' character as an 'escape sequence' as does the C-Compiler inside a string. So while externally you can pass a string, "e:\abc\def..." (each being a single ASCII code), inside the C-Compiler/debugger this will be represented, "e:\\abc\\def\\...".

However, the bug I was reporting, was that when running with debugger from Code:Blocks , it simply jammed and would not load the debugger itself if the backslash character was present at any position in the command line. I could repeat the failure many times.  When just "run" (without debugger) all worked as expected.  So it seemed to be a problem with the debugger loading; however, since further testing I have not been able to replicate the bug! 

[ollydbg]

I agree this is a common mistake made by beginners!

I have been programming since 1979 so not exactly a beginner!

When passing arguments to the program from the command line, you do not use '\\' since the DOS command line processor does not interpret the '\' character as an 'escape sequence' as does the C-Compiler inside a string. So while externally you can pass a string, "e:\abc\def..." (each being a single ASCII code), inside the C-Compiler/debugger this will be represented, "e:\\abc\\def\\...".

However, the bug I was reporting, was that when running with debugger from Code:Blocks , it simply jammed and would not load the debugger itself if the backslash character was present at any position in the command line. I could repeat the failure many times.  When just "run" (without debugger) all worked as expected.  So it seemed to be a problem with the debugger loading; however, since further testing I have not been able to replicate the bug! 

OK, I understand now! Thanks for your explanation.

[nickrt]

Hey - thanks for the reply! It is having great guys like you that help to keep software communities working how they should!  Still, it is not the same as the "old days" when I could type in each hex code to the Z80 and understand 100% what it was doing... with all these layers upon layers of OS, sometimes just getting "hello" out is not so easy!! 

[ollydbg]

Hey - thanks for the reply! It is having great guys like you that help to keep software communities working how they should!  Still, it is not the same as the "old days" when I could type in each hex code to the Z80 and understand 100% what it was doing... with all these layers upon layers of OS, sometimes just getting "hello" out is not so easy!! 

Thank you for sharing your experience. It seems you are a sophisticated programmer.(Your programming life is bigger than my whole life :shock:).

By the way, I still feel the software communities should be more active. Still there are a lot to improve. For about one month,  I try to give my effort to improve CodeCompletion plugin, but my ability is limited , we still need a lot help to make Code::Blocks working better and better.