gcc: access to destroyed stack variable by using reference possible?

Question

Possible Duplicate:
Can a local variable's memory be accessed outside its scope?

Consider the following simple C++ code:

#include <iostream>

struct Test
{
    Test( int i )
        :   ref( i ),
            ptr( &i ) {}

    int &ref;
    int *ptr;
};

int main()
{
    Test t( 5 );

    std::cout << t.ref << std::endl;
    std::cout << *t.ptr << std::endl;

    return 0;
}

The class Test stores a pointer and a refernce to the local variable i living on the stack. I would presume that i get's destroyed after returning from the Test constructor. But obviously this is not the case. As this is the output of the program:

5
134513968

The result of the access to the pointer is what I would expect: a random value that changes with every run. But the reference access always results in 5 - just if the local variable i still exists.

Can anyone explain this behaviour to me? I'm using g++ on 64bit Linux (version 4.6.3).

Regards, enuhtac

Thanks for your answers. I was just wondering if I missed some very special topic from the C++ standard. Obviously this is not the case. It was pure chance that this little program gave the right answer — user1375834, May 04 '12 at 20:44

Seth Carnegie · Answer 1 · 2012-05-04T20:39:00.580

6

Accessing a destroyed variable like that causes undefined behaviour. It's only a coincidence it printed 5; it could have printed -4390843 or hello world, crashed your computer, ignited the atmosphere, or bought pizza with your credit card.

Also, there's really no point trying to guess what happened because compilers can do some very weird things with your code when they generate the assembly. It's an exercise in futility (but if you really want to know where all the bits are coming from and where they've been, just debug it).

edited May 04 '12 at 20:39

answered May 04 '12 at 20:32

Seth Carnegie

73,875
22
181
249

3

Where can I get some crashing behavior like that@@@@@@ - `SEGFAULT Pizza on the way` – lukecampbell May 04 '12 at 20:33
@lukecampbell easy: `signal(SIGSEGV, Dominos);` – JoeFish May 04 '12 at 20:36
@JoeFish I think I just found a new project for this weekend, just need to find out if Dominos.com has a RESTful API (doubt it) – lukecampbell May 04 '12 at 20:37

score 1 · Answer 2 · answered May 04 '12 at 20:33

When constructing t you get the memory address of where i is stored during construction. When you call std::cout << t.ref there has been no reason for that memory location to be used for something else, so the value is still there.

However it's nothing you can trust. It's undefined behaviour to access that memory location after i goes out of scope.

score 0 · Answer 3 · answered May 04 '12 at 20:32

0

I haven't inspected it closely but just because you popped off the stack doesn't mean that the contents were overridden or changed, the value in that address remains unchanged. Add some more method calls afterward and it should change.

answered May 04 '12 at 20:32

lukecampbell

14,728
4
34
32

score 0 · Answer 4 · answered May 04 '12 at 20:33

0

It's not guaranteed that local variable will be deleted immediately. It can remain in memory. But it is undefined behaviour and it's dangerous.

answered May 04 '12 at 20:33

Pavel Strakhov

39,123
5
88
127

score 0 · Answer 5 · edited May 23 '17 at 11:48

This answer gives a nice analogy for how you can think about this:

You rent a hotel room. You put a book in the top drawer of the bedside table and go to sleep. You check out the next morning, but "forget" to give back your key. You steal the key!

A week later, you return to the hotel, do not check in, sneak into your old room with your stolen key, and look in the drawer. Your book is still there. Astonishing!

How can that be? Isn't the contents of a hotel room drawer inaccessible if you haven't rented the room?

gcc: access to destroyed stack variable by using reference possible?

5 Answers5