This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Locals claimed to be out of scope by debugger

I regularly get this when debugging. Optimisations are turned off. Current instance exhibits it perfectly - linked list management where I have just printed some of the local variables and am about to add them to the list. On return from teh fn that adds them to list the list is out of scope. There are quite a lot of local variables (14) because I am trying to track a bug. "not in scope" reported in both watch window and call stack.

e.g.
printf("MIL Section [%s] key <%s> val <%s>\r\n", entry.section ? entry.section : "NULL", entry.key, entry.value);
if (entry.section)
{ strcpy(section, entry.section);
} AddEntryToList(&mil_list, entry.section, entry.key, entry.value, section);

when on the line
if (entry.section)
the local var "entry" apparently is out of scope.

Anyone found a way of giving the package (MDK on STM32) a thump - I've tried a complete rebuild and restarting the IDE

Parents
  • It seems like the debugger has a max resource allocation for each function so can only display the info on the 1st N variables so re-order them so that the ones you are interested are declared soonest in the function, rebuild and hopefully you will be able to realistically debug again.

    If it is the case, it is the sort of limitation I'd probably write for a quick homer but for a marketed product it is worrying - very poor coding

Reply
  • It seems like the debugger has a max resource allocation for each function so can only display the info on the 1st N variables so re-order them so that the ones you are interested are declared soonest in the function, rebuild and hopefully you will be able to realistically debug again.

    If it is the case, it is the sort of limitation I'd probably write for a quick homer but for a marketed product it is worrying - very poor coding

Children
  • The compiler -- even at -O0 -- may have re-arranged allocation of variables or execution of the code from what you expect. If so, setting a breakpoint on 'if ( entry.section ) {' might actually be on code executed before the printf, which could mean that 'entry' isn't visible to the debugger yet.

    Have you taken a look at the generated assembly to see whether the breakpoint is where you expect it to be?

    The Keil debugger will usually let you set a breakpoint right at the function entry point. That's a good place to observe function arguments.

  • Well the printf has happened as I see the output - it is purely the variables being out of scope