Click here to Skip to main content
14,027,446 members
Click here to Skip to main content
Add your own
alternative version


28 bookmarked
Posted 30 Jan 2012
Licenced CPOL

A Study on Corruption

, 30 Jan 2012
Rate this:
Please Sign up or sign in to vote.
Do you believe that memory corruption will generate an immediate, repeatable crash? Some programmers actually do...


You may have met programmers who believe that a memory corruption will always, immediately, generate some kind of visible result (most likely a program crash): I have. I wish they were right.


Memory corruption changes the contents of memory at unwanted locations, thus changing the values of the variables stored at those locations. In real life, variables hold meaningful data, and a change to those data will have some bad results. Among others: calculations returning the wrong results, programs crashing, programmers losing jobs, and hackers getting access to sensitive information. The sample project shows a case of memory corruption that actually does nothing but change the value of a few variables. No Hollywood-style explosions, no loud screeching noises.

Wikipedia says: "Memory corruption happens when the contents of a memory location are unintentionally modified due to programming errors"

Don't take my word for it, go ahead, check it. The link is right here: You're back already? Let's go on.

Again from Wikipedia: "In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory."

So far I've proved to you that I can copy and paste. But what's the point? Well, the point of this article is that memory corruption, like other kinds of corruption, can and should be prevented. We'll get to that eventually. Just bear with me for a while. I hope you'll have some fun along the way.

Let's corrupt some memory!

Let's have a look at some parts of the sample program (.sln and .dsw provided):

void OverflowMyBuffer(char *szTest)
    // Copy a string of size 13 into a buffer
    // of unknown size. Its size may be just 3 bytes...
    strcpy(szTest, "Hello, world!");  

This is the easiest way to overflow a buffer: strcpy (or memcpy) into its address (the address of its first byte) something bigger than its allocated size. For instance, the string "Hello, world!" is 14 bytes long (counting the ending zero); if the buffer szTest is shorter than that, you'll get a buffer overflow.

void test ()
    const char format[] = "* * * * * nine = %d, eight = %d, seven = %d, szSmallBuffer = '%s'\n";
    // Const everywhere: this cannot change, right?
    // The compiler would tell us, wouldn't it? Well, the contents
    // of this array will be corrupted by a buffer overflow. Stay tuned...
    const int const arr[3] = { 9, 8, 7 };  
    char szSmallBuffer[3];
    // The buffer has no room for the ending zero, but VC++ doesn't seem to mind... 
    strcpy(szSmallBuffer, "abc"); 
    // The next line prints * * * * * nine = 9, eight = 8,
    //       seven = 7, szSmallBuffer = 'abc'; not bad.
    printf(format, arr[0], arr[1], arr[2], szSmallBuffer); 
    // The next line prints * * * * * nine = 1998597231,
    // eight = 1684828783, seven = 33, szSmallBuffer = 'Hello, world!'
    // 33 is the ANSI code for '!'; suspicion arises...
    printf(format, arr[0], arr[1], arr[2], szSmallBuffer); 
    // The next line prints: arr as a string: 'o, world!'
    printf("arr as a string: '%s'\n", arr); 

The function test() is the interesting one. First a few variables get declared and initialized, then a call to printf() shows that their values are as expected. So far, so good.

Then OverflowMyBuffer() is called: this function does not receive a pointer to arr[], and has no inkling of its existence.

After that call, the values in the array arr[], that was not passed to the function, have changed: The last two printf() calls show that fact, and the new contents of the double-const array.

int _tmain(int argc, _TCHAR* argv[])
    printf("\n-----\nIn main, before test()\n-----\n");
    printf("\n-----\nIn main, after test()\n-----\n");
    return 0;

Not much to see here. The function 'test()' above was the interesting one.

The output of the program is:

In main, before test()
* * * * * nine = 9, eight = 8, seven = 7, szSmallBuffer = 'abc'
* * * * * nine = 1998597231, eight = 1684828783, 
                    seven = 33, szSmallBuffer = 'Hello, world!'
arr as a string: 'o, world!'

In main, after test()

What if the contents of arr[] were not just a few idle integers, but important data? For instance: a corrupt pointer may make a program crash, a corrupt variable holding the distance between your ship and the iceberg may send you swimming in very cold waters.

Beginner's aside

- Now, wait a minute! - someone may say: - If the function OverflowMyBuffer() has no access to the variable arr[], how can it mess with its contents?

Well, that's exactly the problem with memory corruption. Using pointers, you can mess with memory everywhere. Consider this: *((int *) rand()) = 0xDeadBeef; Pretty, right? This code tries to plant an arbitrary value in a random position in the memory of your process: if there is a variable there (for all I know, there might be) its value will be modified; if the random pointer points to unallocated memory, or memory occupied by code, strange things will happen.

The point at last

Considering that there are Wikipedia articles on buffer overflow and memory corruption, what's the point of this article?

There are two:

A memory corruption will not necessarily generate an immediate, repeatable crash

Some time ago, a colleague, looking for a bug, searched a few thousand lines of code for all appearances of an integer variable whose value was mysteriously changing, set breakpoints everywhere the variable appeared, and saw the value of the variable change without any apparent reason. He asked me to take a look: how could that happen? Since you're reading this article, you may have deduced that it was memory corruption due to a buffer overflow. At the time, it wasn't obvious: the code was something like this:

// This is pseudo-code. 
int x = 14; // 32 bits = 4 bytes. Contents: { 14, 0, 0, 0 };
            // The x86 processor family is little endian. 
char str[20]; // Declared after x, which means (str + 20 == &x);
              // don't expect (str - 4 == &x). 

// ... many, many lines of code: x is not touched ...

// The database field is of size 20, the function
// LoadDatabaseFieldIntoVariable() calls strcpy;
// the ending zero of str[] overflows into the least significant byte of x
LoadDatabaseFieldIntoVariable(SomeDatabaseField, str); 

// ... many, many lines of code: x is not touched ...

// x is no longer 14, but zero. Huh?
// Nobody ever touched it! What happened?
char * ptr = malloc(x);
// .. a few more lines of code ...
strcpy(ptr, "Hello, world!"); // Crash!

We set breakpoints wherever str was touched, added a watch for x, and the bug was solved.

If you see production code randomly failing at customer sites, to succeed after a couple of minutes, with identical input; if you see simple calculations sometimes returning weird results, and a minute later the right result; if you cannot reproduce the unwanted behavior under your debugger; if your teammates are blessed with healthy programmers' ego ("if there's a bug, it's not in my code"); those are usual symptoms of memory issues: either corruption, or failed, unchecked memory allocation (which is a subject for a totally different article), or, in multithreaded code, a race condition (again, out of the scope of this article).

Buffer overflows can be avoided

With a few simple precautions, you can make buffer overflows a thing of the past:

  • Don't use C-style strings: use std::string, or WTL/ATL/MFC CString, or CComBSTR/_bstr_t. All of them manage their own memory.
  • Don't use C-style arrays: use STL containers. Again, they protect you against buffer overflows.
  • If you absolutely must write a function that receives a C-style array as parameter and modifies its contents, take also a second parameter of type size_t, with the count of elements, and use it to avoid buffer overflow. Just like strncpy().

Another frequent cause of memory corruption is dangling pointers; I didn't bump into any on the last few weeks. If you're interested in their prevention, and a Google or Bing search for "how to prevent dangling pointers" didn't help, leave me a comment below.

I hope you enjoyed this article: in any case, thank you for taking the time to read it. Happy programming!


  • 2012, January - Posted.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Pablo Aliskevicius
Software Developer (Senior)
Israel Israel
Pablo writes code for a living, in C++, C#, and SQL.

To make all that work easier, he uses some C++ libraries: STL, ATL & WTL (to write Windows applications), and code generation.

Pablo was born in 1963, got married in 1998, and is the proud father of two wonderful girls.

Favorite quotes:
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, "The Devil's Dictionary", published in several newspapers between 1881 and 1906).
"You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).

You may also be interested in...

Comments and Discussions

QuestionNice work Pin
Mike Hankey30-Jun-14 9:41
professionalMike Hankey30-Jun-14 9:41 
AnswerRe: Nice work Pin
Pablo Aliskevicius30-Jun-14 9:44
memberPablo Aliskevicius30-Jun-14 9:44 
GeneralMy vote of 5 Pin
Mike Meinz19-Jun-13 2:36
memberMike Meinz19-Jun-13 2:36 
GeneralRe: My vote of 5 Pin
Pablo Aliskevicius19-Jun-13 3:18
memberPablo Aliskevicius19-Jun-13 3:18 
GeneralMy vote of 5 Pin
KjellKod.cc12-May-12 8:43
memberKjellKod.cc12-May-12 8:43 
GeneralRe: My vote of 5 Pin
Pablo Aliskevicius12-May-12 9:43
memberPablo Aliskevicius12-May-12 9:43 
QuestionMicrosoft Application Verifier Pin
Rolf Kristensen7-Feb-12 8:50
memberRolf Kristensen7-Feb-12 8:50 
AnswerRe: Microsoft Application Verifier Pin
Pablo Aliskevicius7-Feb-12 22:15
memberPablo Aliskevicius7-Feb-12 22:15 
GeneralMy vote of 3 Pin
Hei-Tech7-Feb-12 2:26
memberHei-Tech7-Feb-12 2:26 
GeneralRe: My vote of 3 Pin
Stefan_Lang7-Feb-12 3:57
memberStefan_Lang7-Feb-12 3:57 
GeneralRe: My vote of 3 Pin
Hei-Tech7-Feb-12 5:17
memberHei-Tech7-Feb-12 5:17 
GeneralRe: My vote of 3 Pin
Stefan_Lang7-Feb-12 22:02
memberStefan_Lang7-Feb-12 22:02 
Questiondebug magic values Pin
Tomek Anuszkiewicz6-Feb-12 13:17
memberTomek Anuszkiewicz6-Feb-12 13:17 
AnswerRe: debug magic values Pin
Pablo Aliskevicius6-Feb-12 18:48
memberPablo Aliskevicius6-Feb-12 18:48 
GeneralMy vote of 5 Pin
ThatsAlok31-Jan-12 18:57
memberThatsAlok31-Jan-12 18:57 
excellent Smile | :)
GeneralRe: My vote of 5 Pin
Pablo Aliskevicius31-Jan-12 19:12
memberPablo Aliskevicius31-Jan-12 19:12 
QuestionExample from the field Pin
Roger Allen31-Jan-12 6:33
memberRoger Allen31-Jan-12 6:33 
SuggestionFormatting issue. Pin
Nish Nishant30-Jan-12 7:05
sitebuilderNish Nishant30-Jan-12 7:05 
GeneralRe: Formatting issue. Pin
Pablo Aliskevicius30-Jan-12 7:31
memberPablo Aliskevicius30-Jan-12 7:31 
GeneralRe: Formatting issue. Pin
Nish Nishant30-Jan-12 7:32
sitebuilderNish Nishant30-Jan-12 7:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web02 | 2.8.190419.4 | Last Updated 30 Jan 2012
Article Copyright 2012 by Pablo Aliskevicius
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid