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;
}

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())
      /*...*/
}

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);

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...

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.

as i said top, i don't think it is a bug, but a user problem...

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)

the i is first initialized after the "for" call. So when you put the break point in the for line i is uninitialized....

3/ Breakpoints do not always work, e.g they do not work when I place them on the last instruction in a loop

this could be a optimizing problem... please post some example code....

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.

for me it is working (see image)... code to reproduce please...

I do use optimized code but this did not seem to be a problem with 10.04

The root of may problems in debugging... Turn off the optimization and your debugging-live will be easier

greetings

[YannisP]

if you find a "bug", pleas enable "Full (Debug) Log" in the debugger settings, and post the Debugger log...

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)

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.

as i said top, i don't think it is a bug, but a user problem...

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.

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)

the i is first initialized after the "for" call. So when you put the break point in the for line i is uninitialized....

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

3/ Breakpoints do not always work, e.g they do not work when I place them on the last instruction in a loop

this could be a optimizing problem... please post some example code....

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.

for me it is working (see image)... code to reproduce please...

I do use optimized code but this did not seem to be a problem with 10.04

The root of may problems in debugging... Turn off the optimization and your debugging-live will be easier

greetings

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

[BlueHazzard]

if you find a "bug", pleas enable "Full (Debug) Log" in the debugger settings, and post the Debugger log...

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)

no, i'm just a user who try to help other users
i think oBFusCATed is the debugger maintainer here, probably he could help more then me...

[Alpha]

Done all ready, actually Code::Blocks itself "messaged" it's developers (you?) 3 times [...]

@devs: I have seen the crash handler occasionally, do we actually receive the reports it sends?  Or do they disappear into cyberspace?

[Jenna]

C::B does not send any crash message to the outer world automatically.
It creates a crash-report in C::B's exe-folder on windows (codeblocks.rpt) and in a sub-folder of the linux temp-directory.
I don't know where it is placed on Mac, but I gues in /tmp also.
It's up to th euser to post it here or attach it to a bug-report.
If th esecond is done, it's always good to post here also (with a link to the bug-report), so more people notice it.