Stack Corruption in C++

Stack corruption in C++

1. You could have a random/undefined pointer that ends up pointing to the stack, and write though that.
2. An assembly function could incorrectly setup/modify/restore the stack
3. Cosmic waves could flips bits in the stack.
4. Radioactive elements in the chip's casing could flip bits.
5. Anything in the kernel could go wrong and accidentally change your stack memory.

But those are not particular to C++, which doesn't have any idea of the stack.

Avoid stack corruption while writing to a pointer location

Simply you have to design API in such way that type of the value is clear.

So for example:

bool GetIntValue(const char* key, int* val) {
     if(val != NULL && IsIntValue(key)) {
         // find the value using the key with some logic of library
         // lets assume found value is a int
         int foundValue = 34;
         val = foundValue;
         return true; 
     }
     return false;
}

bool GetSizeValue(const char* key, size_t* val) {
     if(val != NULL && IsSizeValue(key)) {
         // find the value using the key with some logic of library
         // lets assume found value is a int
         size_t foundValue = 12;
         val = foundValue;
         return true; 
     }
     return false;
}

...

Or other way:

enum Types {
   Int,
   Size,
   ....
};

struct Variant {
   enum Types type;
   union {
       int integer;
       size_t size;
       ....
   };
};

bool GetVariantValue(const char* key, struct Variant* val) {
     if(val != NULL) {
         ...
         *val = MakeIntVariant(33);
         return true; 
     }
     return false;
}

C++ stack and heap corruption

You have to be careful with terminology here. Will the stack be "corrupted" for the remainder of your program's life? It may be; it may not be. In this instance you've only corrupted data within the current stack frame, so once you're out of that function call, in practice your "corruption" will have gone.

But that's not quite the whole story. Since you've overwritten a variable with bytes that aren't supposed to be there, what knock-on effects might that have on your program? The consequences of this memory corruption could feasibly be logically passed on to other function scopes, or even other computers if you're sending this data over a network connection and the data is no longer in the expected form. (Typically, your data protocol will have safety features built into it to detect and discard unexpected forms of data; but, that's up to you.)

The same is true of heap corruption. Any time you overwrite the bytes of something that is not supposed to be overwritten, and any time you do so with arbitrary or unknowable data, you run the risk of potentially catastrophic consequences that may logically last well beyond the lifetime of your program.

Within the scope of C++ as a language, this condition is summed up in a specific phrase: undefined behaviour. It states that you can't really rely on anything at all after you've corrupted your memory. Once you've invoked UB, all bets are off.

The one guarantee that you usually have in practice is that your OS will not allow you to directly overwrite any memory that does not belong to your program. That is, corrupting the memory of other processes or of the OS itself is very difficult. The memory model of modern OSs is deliberately designed that way in order to keep programs isolated and prevent this kind of damage from broken programs and/or viruses.

How can you catch memory corruption in C++?

In general you have to solve problem of code sanitation, which is quite a broad topic. It sounds like you may have either out-of-bound write, or use of a dangling pointer or even a race condition in using a pointer, but in latter case bug's visibility is affected by obsevation, like the proverbial cat in quantum superposition state.

A dirty way to debug source of such rogue write is to create a data breakpont. It is especially effective if bug appears to be deterministic and isn't a "heisenbug". It is possible in MSVS during debug session. In gdb it is possible by using watch breakpoints.

You can point at the std::string storage or, in your experimental case, at the front padding array to in attempt to trigger breakpoint where a write operation occurs.

C++ Corrupt stack around Variable

I don't think your algorithm for generating the Roman numeral equivalent is correct. I passed in 100, and this is the array it was constructing

i 0    ╠╠╠╠╠╠╠╠╠╠
i 3    DDD╠╠╠╠╠╠╠
i 6    DDDCCC╠╠╠╠
i 9    DDDCCCLLL╠
i 12    DDDCCCLLLX
i 15    DDDCCCLLLX
i 15    DDDCCCLLLX

Which is certainly not the roman numeral for 100. It looks like you need to recheck the else portions of your for loops, they are inserting chars when not needed

    for (int j = 0; j < 3; j++)
    {
        if (D > 3)
        {
            romanArray[i] = 'C';
            i++;
            counter--;
        } else
        {
            romanArray[i] = 'D';
            i++;
            counter--;
        }
    }

D was zero but this code still inserts 3 'DDD'. You likely need something like

} else if (D > 0) {

stack corruption detected when use memset in c++ from JNI Android

Your input array is 8 bytes. The data parameter is a pointer to input, and the data_size parameter is 8, so theblock_size variable is calculated as 12. Your memset() is writing 4 0x00 bytes to &data[data_size], aka &input[8], which is out of bounds of the input array. So, you have a buffer overflow that is corrupting stack memory surrounding the input array.

The subsequent for loop after the memset() is also accessing the input array's elements out of bounds, too.

input is a fixed sized array. Accessing elements outside of its bounds does not make it grow larger.

---

Related Topics