0

I am working on ANSI C and having some issues with the pointers.

That is that after a point in my program the pointer's values change without me interfering, is something like overwriting them.

I know that this could happen in C, but while being a beginner, can not find a remedy for that.

Is there a straightforward way of solving this? As I understand, many people will have faced similar issues.

Thank you guys for your answers,were very helpful,was indeed a memory problem solved by just allocating larger blocks of memory!!! Thank you again!!!!

Rizias
  • 107
  • 2
  • 1
    probable a buffer overflow somewhere else – ratchet freak Feb 06 '14 at 15:06
  • 2
    If it's a specific pointer getting corrupted, run under a debugger and add a watchpoint on the pointer. It'll break execution when something overwrites it. Otherwise, try using something like valgrind, or a static analysis tool, to detect buffer overruns. – Useless Feb 06 '14 at 15:10
  • 2
    This could happen for any number of reasons. If you post the code we could take a look although [Stackoverflow](http://www.stackoverflow.com) might be a better fit in that case. Also, there are tools that can help if you're really stuck. – Robbie Dee Feb 06 '14 at 15:11
  • Thank you guys for replies!!!@Useless,i do run the debugger but the execution doesn't stop,is it because of virtual studio that i am using??@Robbie Dee Unfortunately,i cannot share the code,but please if you like tell me some of that reasons so i can investigate. – Rizias Feb 06 '14 at 15:21
  • 1
    if your code isn't windows specific you could try valgrind – jk. Feb 06 '14 at 15:33
  • Could be a string overrun, going off the end of an array, memcpy with overlapping memory locations etc etc etc. As for tools, I used to use [BoundsChecker](http://www.borland.com/products/devpartner/read/) many years ago but I daresay there are newer ones now – Robbie Dee Feb 06 '14 at 16:16
  • @GiwrgosRizeakos Allocating more memory does not FIX your problem, it only hides it. The problem shouldn't happen regardless of the amount of memory you allocate. You should ALWAYS be checking the size of arrays before writing to them. If you don't, then it is a bug. – Jonathan Henson Feb 06 '14 at 18:13
  • @Jonathan Henson I agree with you,and thank you for your comment,the particular piece of code is modified only for simulation purposes is not the original one.Moreover,isnt it enough that i free the memory in the end of the function?I though that this compensate for any memory i reserve. – Rizias Feb 07 '14 at 10:22
  • If this is just a prototype then I wouldn't worry too much about it, but in general, freeing the memory at the end isn't the issue (though you should certainly do that too), the issue is that if you don't have enough memory you have the issue in the first place. You should NEVER have this issue because you should ALWAYS be checking your array bounds before reading or writing to an array. Even if you didn't have the memory allocation large enough, you should NEVER have code that even has a remote possibility of overflowing a buffer. On older versions of Windows, you might even destroy hardware. – Jonathan Henson Feb 07 '14 at 23:13

3 Answers3

4

You can do several things. On an unmodified 32-bit application in Windows you may be able to use DrMemory.

(I assume you already configured your compiler to issue all the warnings it can. Never understimate the potential troubles hiding behind a "warning").

You might also port your program to Linux (on a VMware virtual machine, maybe) and use Valgrind. Then as soon as you run the program, you will be informed of an array of possible mistakes in the code, complete with file name, line number and description.

Finally, there are "memory checking libraries" (eFence, but there are others) that you will compile/link with your ANSI C program, and will replace most ways in which you can mess up with memory. Sometimes you will also have to include calls to some check function, so that your code becomes something like:

CHECKPOINT
at = getAnotherTree(i++, info);
CHECKPOINT

Then, if you perform a flawed standard call in getAnotherTree(), you will get an error such as

treebuild.c at line 597: strcpy: attempt to copy 192 bytes into 128-byte buffer
ABORTING

and if you do that by hand, for example with

for (i = 0; i < bufSize; i++) {
    buffer[i] = 0;
}

then the second checkpoint will throw an error such as

treebuild.c at line 1080: CHECKPOINT FAILURE

thereby pinpointing the source of the error to something in the program flow between the last known good checkpoint and the failing one.

LSerni
  • 2,411
  • 15
  • 21
2

If you have values being changed and you didn't intentionally write code to change them, then in all likelihood, you are writing to an array and overwriting the buffer. This can do all sorts of things. Usually you will see functions getting called that you didn't intend to be called or not getting called etc... However, it can also corrupt your data. I would carefully investigate all of your memcpy, memmove, strcpy, and array loops and see if you find something. I am pretty sure, just looking at your compiler warnings will tell you what is going on. Msft likes to complain about use of the old c functions that weren't safe.

To avoid this problem, ALWAYS do range checks on arrays.

This may not be the problem, but it seems the most likely. If you would like some more hints, we need to see some code.

In reponse to your edit. Allocating more memory merely hides the symptoms. You have a bug in your code where you are not checking the bounds of your arrays properly before writing to them. Fix the bug, your problem is not really solved until you have done that.

Jonathan Henson
  • 5,039
  • 3
  • 26
  • 33
0

The single-most common pointer bug among beginners seems to trying to store a value into a pointer which is not pointing at a valid memory location.

Typical example:

char* ptr;  // initialized pointer, could point anywhere
*ptr = something; // bug, the program tries to write to "anywhere"

Almost all beginner bugs are different flavours of the above.

The good news is that such bugs are quite easy to track down. Simply single-step with a debugger until the program crashes. The line where it crashed is most likely the incorrect one.