Memory location overwritten

[burningmosfet]

Hello to everybody, me and my colleague are debugging a c-code written for a Renesas R8C11 microcontroller (8 bit architecture) and we found some bugs. The most dangerous of these bugs was that in a particular point of the code, because of a "for" cycle badly written, there was an assignment to an array location out of the array bounds causing overwriting of the variable with ram-address following array[9];

Example:

unsigned char i,k;
...
unsigned char array[10];
...
for(i=0,i<11;i++){                 //ERROR @ iteration i =10; 
      array[i] = k;
}

The question is: how can i know which is the variable that is overwritten whithout going in debug mode (we have space problems so we can't debug)? Is there a way without modifing the code or the compiling/linking options of the project?
I'm sorry for this stupid question but i'm not very familiar to HEW and renesas...

[Salem]

The short answer is you can't know what is being trashed by your overrun.

Your other variables may
- be before the array
- after the array
- not stored at all, but exist entirely in registers.

Even if you knew they were after the array, there may be unknown amounts of padding (hopefully, it would be zero on an embedded processor) between the array and other variables. So any overwrite would land on dead space.

Further, changing ANY compiler flags might change any of the above assumptions.

The short answer is to FIX the code you found by reading the code.

[rags_to_riches]

unsigned char array[10];

The only valid indexes for this array are 0 through 9.

for(i=0,i<11;i++){

You have a comma where you should have a semicolon, and you're overrunning the bound of your array as noted above.

[burningmosfet]

for(i=0,i<11;i++){

You have a comma where you should have a semicolon, and you're overrunning the bound of your array as noted above.[/QUOTE]

Yes it was just an example...

The short answer is you can't know what is being trashed by your overrun.

Your other variables may
- be before the array
- after the array
- not stored at all, but exist entirely in registers.

Even if you knew they were after the array, there may be unknown amounts of padding (hopefully, it would be zero on an embedded processor) between the array and other variables. So any overwrite would land on dead space.

Further, changing ANY compiler flags might change any of the above assumptions.

The short answer is to FIX the code you found by reading the code.

Thanx Salem....We tried a modified code reducing rom space occupation for debug and i noticed there was no padding (no dummy bytes) and effectively a variable was overwritten. Isn't there the possibility to generate (with the original code and in release mode) a map of the ram addresses of the variables?

[CommonTater]

Hello to everybody, me and my colleague are debugging a c-code written for a Renesas R8C11 microcontroller (8 bit architecture) and we found some bugs. The most dangerous of these bugs was that in a particular point of the code, because of a "for" cycle badly written, there was an assignment to an array location out of the array bounds causing overwriting of the variable with ram-address following array[9];

Example:

unsigned char i,k;
...
unsigned char array[10];
...
for(i=0,i<11;i++){                 //ERROR @ iteration i =10; 
      array[i] = k;
}

The question is: how can i know which is the variable that is overwritten whithout going in debug mode (we have space problems so we can't debug)? Is there a way without modifing the code or the compiling/linking options of the project?
I'm sorry for this stupid question but i'm not very familiar to HEW and renesas...

What I'm not getting is why you don't simply reduce the loop to exit at < 10 ... It has a syntax error in it anyway, so you're going to have to fix that... You know it's broken... why not just fix it?

for (i = 0; i < 10; i++)
   array[i] = k;

Either that or increase your array dimension to 11.

[Salem]

I don't get it, if you can modify the code, do so and get on with life?

Why are you trying to construct the past?

Some compilers may give you a detailed map file of where everything is, but that depends entirely on the tool chain you have. For that, you would have to read the manual.

[jimblumberg]

Isn't there the possibility to generate (with the original code and in release mode) a map of the ram addresses of the variables?

It might be possible for your linker to generate a map file that will show the memory locations for your variables and functions. You will need to check your compiler documentation to determine if it supports map file generation and what it takes to generate the file if it is possible.

Jim

[burningmosfet]

What I'm not getting is why you don't simply reduce the loop to exit at < 10 ... It has a syntax error in it anyway, so you're going to have to fix that... You know it's broken... why not just fix it?

for (i = 0; i < 10; i++)
   array[i] = k;

Either that or increase your array dimension to 11.

Sorry I'm afraid i didn't explained well maybe because of my bad English. We started working on a old electronic control unit that sometimes gets locked (and the external watchdog reset it) and we found in the release-code the bug listed above where obviously the for was written correctly for(i=0;i<10;i++)... i simply made a mistake in reporting the example inserting a comma in place of ";"

We obviously corrected the cycle to stop @ the tenth iteration (i=9) but I want to be sure that this bug was responsible of the lock if someone has an idea if this is possible...

It might be possible for your linker to generate a map file that will show the memory locations for your variables and functions. You will need to check your compiler documentation to determine if it supports map file generation and what it takes to generate the file if it is possible.

Jim

thank you jimblumberg it's a good idea, i also thought at it but i'm not familiar to renesas IDE so while i read the (very boring ) documentation i'm wondering if someone has the fast solution

[Salem]

I don't think it's possible for you to categorically say that "this bug" caused "that lockup".

Rather than generating map files, it may be easier to disassemble the code for that function to find out what memory locations are overlapping, then construct code behaviour from that point.

For example, if the last array slot was also the loop counter, then writing zero to the last array slot would also reset the loop variable back to the beginning. That would indeed lock up the code in a never ending loop.

But who says this is the only bug in the code?
If you found one by inspection, I'd bet a dime-a-dozen there will be more in the code.

[burningmosfet]

I don't think it's possible for you to categorically say that "this bug" caused "that lockup".

Rather than generating map files, it may be easier to disassemble the code for that function to find out what memory locations are overlapping, then construct code behaviour from that point.

For example, if the last array slot was also the loop counter, then writing zero to the last array slot would also reset the loop variable back to the beginning. That would indeed lock up the code in a never ending loop.

But who says this is the only bug in the code?
If you found one by inspection, I'd bet a dime-a-dozen there will be more in the code.

our hope is to demonstrate that the variable that regulates a loop is continuosly resetted and this stuck the machine that then will be resetted by the WDG.. but you are right we'll surely keep on debugging the code ..

thanx

[CommonTater]

Here's a thought... Why don't you fix the bug you found, put it back into service and see what happens... If you fixed it, problem solved. If that didn't fix it, then you know there's more than one bug to be worked out... Either way you get the information you need.

Sometimes the best test bed is the end use...

[burningmosfet]

Here's a thought... Why don't you fix the bug you found, put it back into service and see what happens...

The big problem in doing this is that the we can't reproduce the block of the unit. It happens randomly and probably after a particular sequence of events so we will never know certainly if we corrected the bug.

[CommonTater]

Yes you will...
Be confident... assume you fixed it... until it does it again.
It appears to be the only real troubleshooting path you have available.