User forums > Using Code::Blocks
CodeBlocks 12.11 debugger help
gordlonious:
--- Code: ---I'm running CodeBlocks 12.11 on Windows 7. When I try to debug this prgram:
[code]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
int main(int argc, char **argv)
{
//Array that will store unencrypted text
char text[1024];
//get key
printf("Enter your desired key: ");
char key[30];
fgets(key, 30, stdin);
if(key[strlen(key)-1] == '\n')
key[strlen(key) -1] = '\0';
printf("You entered %s as your key ", key);
//get text to encrypt
printf("Enter text you wish to be encrypted: ");
fgets(text, 1024, stdin);
printf("The length of your text is %d\n", strlen(text));
//Declare variables necessary for encryption
int placeofkey = 0;
int placeoftext = 0;
int cypher;
//Encrypt by checking conctents of the plain text, then encyphering it by the amount from the key
for (int i = 0; i < strlen(text); i++)
{
cypher = key[placeofkey] + text[placeoftext];
//Set place of key back to 0 so we can repetitively encrypt with key
if (strlen(key) == placeofkey)
placeofkey = 0;
else if (isspace(text[placeoftext]))
placeoftext++;
else if (isupper(text[placeoftext]))
if (cypher > 90)
{
int wrap = cypher % 90;
int cyphup = 64 + wrap;
printf("%c", cyphup);
placeofkey++;
placeoftext++;
}
else
{
printf("%c", cypher);
placeofkey++;
placeoftext++;
}
else if (islower(text[placeoftext]))
if (cypher > 122)
{
int wrap1 = cypher % 122;
int cyphlo = 96 + wrap1;
printf("%c", cyphlo);
placeofkey++;
placeoftext++;
}
else
{
printf("%c", cypher);
}
else
printf("%c", text[placeoftext]);
}
return 0;
}
--- End code ---
When the debugger gets to any of the printf functions it goes to the stdio.h file, i hit next a couple of times, then the arrow just dissappears, the debugging options get grayed out. Even Stop Debugger doesn't work. Only way to leave is to exit CodeBlocks. Any help is much appreciated![/code]
YannisP:
I have the same problem either in c (e.g printf) or in c++ (e.g cout)
I have also noticed that the debugger:
1/ "freezes" the same way it's dircibed in the previous post when i follow the statements in a loop (hitting F7), it freezes after a variable number of F7 presses.
2/ has problems adjusting between dis-assembly code and the original code
for example if I have a loop: for(int i = 2; i < p; i++) the first time it enters the loop i will be 3 and not 2 as it should.
This is always the case if I place a break point where the for is, it seems to execute the loop at least one before stooping, or if the loop is the first statement in the function. If I places the breakpoint at the caller and "step into" the callee it reacts correctly (if the loop is not the first instruction)
3/ Breakpoints do not always work, e.g they do not work when I place them on the last instruction in a loop
4/ I did not find some way to watch and array or an element of it e.g char array[10], when I enter array in the watches it says "trying to follow a variable which does not lie in memory, when i watch array or array[0] or whatever it shows nothing. The same applies to C++ templates.
5/ does not distinguish between F7 and altF7, in order to follow dis assembly instructions I have to use the toolbar button and the mouse
6/ Step into does not always work e.g in cases like if(a || func()) does not
I have :
--- Code: ---func()
{
for(/*...*/)
for(/*...*/)
if(/*...*/)
/* code ...*/
}
main()
{
if(a || func())
/*...*/
}
--- End code ---
and neither "step in" works or breakpoints in func() no matter where I place them
all the above are problems with v-12.11, there were not present with 10.04. I do use optimized code but this did not seem to be a problem with 10.04
I am using lubuntu 13.04 and gcc 4.8
any suggestions would be highly appreciated
TIA
BlueHazzard:
Hi
--- Code: ---printf("Enter your desired key: ");
char key[30];
fgets(key, 30, stdin);
--- End code ---
if you stop @printf and hit next, i jumps in the stdio.h because there is fgets.... if you push next, the debugger jumps in fgets. fgets waits for a key input from the stream, so the debugger blocks in fgets. The arrow disappear and the debugger gives no respond, because it is blocked in fgets.
This is no bug, but normal behaviour.
BlueHazzard:
if you find a "bug", pleas enable "Full (Debug) Log" in the debugger settings, and post the Debugger log...
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---1/ "freezes" the same way it's dircibed in the previous post when i follow the statements in a loop (hitting F7), it freezes after a variable number of F7 presses.
--- End quote ---
as i said top, i don't think it is a bug, but a user problem...
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---2/ has problems adjusting between dis-assembly code and the original code
for example if I have a loop: for(int i = 2; i < p; i++) the first time it enters the loop i will be 3 and not 2 as it should.
This is always the case if I place a break point where the for is, it seems to execute the loop at least one before stooping, or if the loop is the first statement in the function. If I places the breakpoint at the caller and "step into" the callee it reacts correctly (if the loop is not the first instruction)
--- End quote ---
the i is first initialized after the "for" call. So when you put the break point in the for line i is uninitialized....
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---3/ Breakpoints do not always work, e.g they do not work when I place them on the last instruction in a loop
--- End quote ---
this could be a optimizing problem... please post some example code....
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---4/ I did not find some way to watch and array or an element of it e.g char array[10], when I enter array in the watches it says "trying to follow a variable which does not lie in memory, when i watch array or array[0] or whatever it shows nothing. The same applies to C++ templates.
--- End quote ---
for me it is working (see image)... code to reproduce please...
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm --- I do use optimized code but this did not seem to be a problem with 10.04
--- End quote ---
The root of may problems in debugging... Turn off the optimization and your debugging-live will be easier ;)
greetings
YannisP:
--- Quote from: BlueHazzard on May 05, 2013, 06:24:39 pm ---if you find a "bug", pleas enable "Full (Debug) Log" in the debugger settings, and post the Debugger log...
--- End quote ---
Done all ready, actually Code::Blocks itself "messaged" it's developers (you?) 3 times until now but for other reasons concerning the SpellChecker (it crashes Code::Blocks completely)
--- Quote from: BlueHazzard on May 05, 2013, 06:24:39 pm ---
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---1/ "freezes" the same way it's dircibed in the previous post when i follow the statements in a loop (hitting F7), it freezes after a variable number of F7 presses.
--- End quote ---
as i said top, i don't think it is a bug, but a user problem...
--- End quote ---
I did not reported as a bug, more as a strange bahaviour lowering functionality, but no, it is not waiting for input, also if that was the case it should recover after ending the debugging session, it does not, on the contrary when this happens the debugger does not function anymore until you restart Code:Blocks.
I guess it follows system functions like I/O because there is debug info, but this was not the case with 10.04 and it does not happen every time, I could say that all mentioned problems appear when the code is optimized.
--- Quote from: BlueHazzard on May 05, 2013, 06:24:39 pm ---
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---2/ has problems adjusting between dis-assembly code and the original code
for example if I have a loop: for(int i = 2; i < p; i++) the first time it enters the loop i will be 3 and not 2 as it should.
This is always the case if I place a break point where the for is, it seems to execute the loop at least one before stooping, or if the loop is the first statement in the function. If I places the breakpoint at the caller and "step into" the callee it reacts correctly (if the loop is not the first instruction)
--- End quote ---
the i is first initialized after the "for" call. So when you put the break point in the for line i is uninitialized....
--- End quote ---
sure, and it should be initialized with 2 (in my example) not with 3 as the debugger shows, as a matter of fact 'i' should be undefined until the debugger (the arrow) enters the for loop
--- Quote from: BlueHazzard on May 05, 2013, 06:24:39 pm ---
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---3/ Breakpoints do not always work, e.g they do not work when I place them on the last instruction in a loop
--- End quote ---
this could be a optimizing problem... please post some example code....
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm ---4/ I did not find some way to watch and array or an element of it e.g char array[10], when I enter array in the watches it says "trying to follow a variable which does not lie in memory, when i watch array or array[0] or whatever it shows nothing. The same applies to C++ templates.
--- End quote ---
for me it is working (see image)... code to reproduce please...
--- Quote from: YannisP on May 03, 2013, 04:07:46 pm --- I do use optimized code but this did not seem to be a problem with 10.04
--- End quote ---
The root of may problems in debugging... Turn off the optimization and your debugging-live will be easier ;)
greetings
--- End quote ---
definitely it's due to the optimization, I just find it strange because 10.04 reacted differently, the for - loop problem is annoying though
thanks for your fast response, I'll post some example code the soonest.
regards
Navigation
[0] Message Index
[#] Next page
Go to full version