What is the reason for "stack smashing detected"?

Question

I am new to programming and am currently studying about address typecasting. I don't seem to understand why I am getting this : *** stack smashing detected ***: terminated Aborted (core dumped) when I run the following code??

#include<iostream>
using namespace std;

void updateValue(int *p){
    *p = 610 % 255;
}

int main(){
    char ch = 'A';
    updateValue((int*)&ch);
    cout << ch; 
}

Here's what I understand about the code:

The address of ch is typecasted to int* and passed into the function updateValue(). Now, inside the updateValue() stack, an integer pointer p is created which points to ch. When p is dereferenced, it interprets ch as an int and reads 4(or 8) bytes of contiguous memory instead of 1. So, 'A'(65) along with some garbage value gets assigned to 610%255 i.e. 20.

But I don't understand, what and where things are going wrong?

Doublure

You have undefined behavior, anything can happen. – Rye

@πάνταῥεῖ can you please elaborate?? – Doublure

There's nothing to "elaborate". This behavior is undefined by the C++ standard. Anything can happen, from your program crashing, to running apparently without any problems, to your computer exploding in a fireball. Just because a C++ program compiles, and runs, doesn't mean that it will work correctly. C++ does not work this way. If a C++ program does something that's undefined by the C++ standard, you have no warranty as to what the results will be. The End. – Colorcast

You program is writing 4 bytes memory, you was owning only 1 byte of the 4 bytes written, so your program is literally overwriting memory that doesn't own. This action can cause any kind of problem. It can make crash the whole OS, only your program, or run with no apparent problem. – Pharisee

The C++ standard says any behaviour is allowed, so crashing with the error "stack smashing detected" is allowed. – Cluny

"I am new to programming and am currently studying about address typecasting." The person teaching you is doing you a disservice. This kind of cast should not be taught. – Cluny

@Pharisee ... so your program is literally overwriting memory that doesn't own... that's a bit misleading, it does not matter if the program owns that memory or not. In the shown case the program might very well own that memory, but it might be just memory that something else of the program and that part becomes corrupted due to that. – Carapace

@Carapace Yeah, A cleaner way of describe it would be that your program is literally overwriting memory that its logic doesn't own. Prakhar if you still haven't a clear idea about what's causing your problem you may look at this – Pharisee

What and where things are going wrong? C++ is not a nanny language. It expects the programmer to not have ill-formed programs that cause undefined behavior. So both the "what and where things are going wrong" is the programmer creating bad code, and compiling it. In the olden days, we'd call this a PEBKAC (problem exists between keyboard and chair) error, or PICNIC (problem in chair, not in computer) error. – Ceratoid

Answer 1

The problem is that you're typecasting a char* to an int* and then dereferencing p which leads to undefined behavior.

Undefined behavior means anything¹ can happen including but not limited to the program giving your expected output. But never rely(or make conclusions based) on the output of a program that has undefined behavior. The program may just crash.

So the output that you're seeing(maybe seeing) is a result of undefined behavior. And as i said don't rely on the output of a program that has UB. The program may just crash which happens in your case.

For example, here the program crashes, but here it doesn't crash.

So the first step to make the program correct would be to remove UB. Then and only then you can start reasoning about the output of the program.

---

^{1For a more technically accurate definition of undefined behavior see this where it is mentioned that: there are no restrictions on the behavior of the program.}

Jodyjoe

Answer 2

when p is dereferenced, it interprets ...

When you indirect through the reinterpreted p and access an object of the wrong type, the behaviour of the program is undefined.

what and where things are going wrong?

Things started going wrong when you reinterpreted a pointer to one type as a pointer to an unrelated type.

Some rules of thumb:

• Don't use reinterpret casts until you know what it does. They are difficult to get right, and are rarely useful.
• Don't use reinterpret casts when it would result in undefined behaviour.
• Don't use C-style casts at all.
• If you think that you need to reinterpret cast, then take a few steps back, and consider why you think that you need it.

Beer

Answer 3

But I don't understand, what and where things are going wrong?

In this statement

*p = 610 % 255;

the memory that does not belong to the object ch that has the type char is overwritten. That is instead of one byte occupied by the object ch there are overwritten 4 bytes that correspond to the allocated memory for an object of the type int.

Phalansterian