uVision3/ARM watch window bug...?

The uVision3 IDE watch window shows the value of pString incorrectly (when stopped on a breakpoint in the "bug" function), unless pString is actually referenced in the function (by, for example, uncommenting the line "pString[0] = 0"). This is true even if the code optimizations are set to the lowest level possible.

#include <string.h>

int bug(int *nState,char *pString)
{
    *nState = 0;
//    pString[0] = 0;
    return(0);
}

void main(void)
{
    int foo = 0;
    char *bar;
    char s[] = "KEIL uVision3 for ARM\r";
    bar = s;
    bug(&foo,bar);
    while(1);
}

Please spare me from comments about not passing parameters to functions if you're not going to reference them, etc. I discovered this bug while testing some code I was prototyping, before the code actually used the parameter passed to it. I'm just trying to give some feedback to the KEIL folks so that they know about this bug.

Parents
  • What I tried to say was that this problem was found when creating the function stubs for a new module. The 'guts' of the functions had not been filled in yet, but as they were being filled in I ran the debugger to make sure that the proper info was correctly making it to appropriate functions. The parameter in question has since been used by the function that led to this discovery.

    I do know that it caused me some confusion, concern, and it wasted some of my time to perform an investigation to determine why the debugger was telling me that the info I was trying to get to a function just wasn't getting there correctly. The bottom line is that it appears that the debugger was just giving me incorrect information.

    It may be that this symptom is indicative of other problems, and I'm just trying to let the folks at KEIL know that an error surfaced with their tools, so that they have an opportunity to look into it, should they desire to do so. I'm sure that other developers would like to be spared from as many tool issues as possible. No one likes to waste their time.

Reply
  • What I tried to say was that this problem was found when creating the function stubs for a new module. The 'guts' of the functions had not been filled in yet, but as they were being filled in I ran the debugger to make sure that the proper info was correctly making it to appropriate functions. The parameter in question has since been used by the function that led to this discovery.

    I do know that it caused me some confusion, concern, and it wasted some of my time to perform an investigation to determine why the debugger was telling me that the info I was trying to get to a function just wasn't getting there correctly. The bottom line is that it appears that the debugger was just giving me incorrect information.

    It may be that this symptom is indicative of other problems, and I'm just trying to let the folks at KEIL know that an error surfaced with their tools, so that they have an opportunity to look into it, should they desire to do so. I'm sure that other developers would like to be spared from as many tool issues as possible. No one likes to waste their time.

Children
More questions in this forum