Memory location overwritten

This is a discussion on Memory location overwritten within the C Programming forums, part of the General Programming Boards category; Hello to everybody, me and my colleague are debugging a c-code written for a Renesas R8C11 microcontroller (8 bit architecture) ...

  1. #1
    Registered User
    Join Date
    Mar 2011
    Posts
    5

    Memory location overwritten

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

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,418
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    a_capitalist_story
    Join Date
    Dec 2007
    Posts
    2,648
    Code:
    unsigned char array[10];
    The only valid indexes for this array are 0 through 9.

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

  4. #4
    Registered User
    Join Date
    Mar 2011
    Posts
    5
    Code:
    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...

    Quote Originally Posted by Salem View Post
    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?
    Last edited by burningmosfet; 03-13-2011 at 08:38 AM.

  5. #5
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by burningmosfet View Post
    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:
    Code:
    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?
    Code:
    for (i = 0; i < 10; i++)
       array[i] = k;
    Either that or increase your array dimension to 11.

  6. #6
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,418
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  7. #7
    Registered User
    Join Date
    May 2010
    Posts
    2,676
    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

  8. #8
    Registered User
    Join Date
    Mar 2011
    Posts
    5

    Thumbs up

    Quote Originally Posted by CommonTater View Post
    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?
    Code:
    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...

    Quote Originally Posted by jimblumberg View Post
    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
    Last edited by burningmosfet; 03-13-2011 at 09:23 AM.

  9. #9
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,418
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  10. #10
    Registered User
    Join Date
    Mar 2011
    Posts
    5
    Quote Originally Posted by Salem View Post
    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

  11. #11
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    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...

  12. #12
    Registered User
    Join Date
    Mar 2011
    Posts
    5
    Quote Originally Posted by CommonTater View Post
    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.

  13. #13
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Bug in Best-Fit Memory Allocation program (Simulation)
    By RommelTJ in forum C Programming
    Replies: 6
    Last Post: 12-13-2009, 03:43 PM
  2. Memory usage and memory leaks
    By vsanandan in forum C Programming
    Replies: 1
    Last Post: 05-03-2008, 05:45 AM
  3. Reading particular memory location ?
    By realnapster in forum C Programming
    Replies: 15
    Last Post: 05-03-2006, 11:35 AM
  4. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 01:15 AM
  5. Location of member functions in memory
    By bennyandthejets in forum C++ Programming
    Replies: 4
    Last Post: 12-05-2003, 08:30 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21