Trying to deliberately induce memory leak and stackoverflow but not seeing memory grow or program slow computer down

Question

Given this code:

#include <iostream>
#include <sys/types.h>
#include <unistd.h>


int infiniteRecursion(int i) {
    std::cout <<getpid() <<": "<< i << std::endl;
    auto x = new int[i];
    x[0] = 2;
    int f[999999999];
    return 1 + infiniteRecursion(i+1);
}

int main() {
    auto b = new int[3000000000000];
    auto c = new int[3000000000000];
    auto d = new int[3000000000000];
    auto e = new int[3000000000000];
    auto f = new int[3000000000000];
    auto g = new int[3000000000000];
    std::cout<<getpid()<<std::endl;
    std::cout<<infiniteRecursion(99999999999);
}

and running this command:

watch "smem -k | grep 31797"

where 31797 is the process id to see the memory grow. The problem is my system never slows down and the memory the PSS doesn't ever change. How would I be able to visualize a memory leak by watching memory grow?

Also secondary to this is I'm also trying to induce stack overflow but it's just not happening, this thing keeps going.

edit: when I comment out the cout statement in the recursive function the function instantly returns! and prints out 0. The program exits with code 0. Is there some optimization going on here?

Included screenshot because sort of relevant as this typically doesn't happen except for on my system:

Try removing any `std::cout` output. That can slow down your code significantly. — tadman, Dec 09 '20 at 22:24
Are you sure this is running correctly? Do these allocations succeed? — tadman, Dec 09 '20 at 22:24
related/dupe: https://stackoverflow.com/questions/30171528/how-to-dynamically-allocate-big-memory-like-10-g-using-new-operator-in-c-on — NathanOliver, Dec 09 '20 at 22:25
@tadman it doesn't crash and I see the output so I'm assuming it succeeds. — Brian Yeh, Dec 09 '20 at 22:26
For what it's worth this runs for about 0.5s on my machine, then pops a segmentation fault. — tadman, Dec 09 '20 at 22:26
@tadman it's not doing anything for mine. I'm literally trying my best to make this thing die, does anyome know what is going on? It just keeps going and going. — Brian Yeh, Dec 09 '20 at 22:28
Again, I think you're measuring how slow your terminal is. Mine gets to around `174670` before crashing. Yours could take longer if you have a larger stack and/or a slower terminal. Remove any output and it will run more quickly. — tadman, Dec 09 '20 at 22:28
I wonder if the compiler's being a smarty-pants and optimizing out the allocations along with the code that has no observable behaviour?. — user4581301, Dec 09 '20 at 22:29
A) How big is your stack? B) How much memory does your system have? — tadman, Dec 09 '20 at 22:30
The test I did was with the default stack size of 8MB. My system has 32GB. — tadman, Dec 09 '20 at 22:31
Explains how you got it to run at all. The initial 18 GB killed my run dead instantly. Where did I put the old Cray... — user4581301, Dec 09 '20 at 22:32
On my system it's something you can discover with `ulimit`. If you're using Windows I'm not sure where that's configured. — tadman, Dec 09 '20 at 22:33
Wierd if I comment out the IO in the recursive function the process finishes with exit code 0 and it prints 0 as the result of the recursion. — Brian Yeh, Dec 09 '20 at 22:37
@BrianYeh -- Maybe the compiler is smart -- did you build your program with compiler optimizations set? — PaulMcKenzie, Dec 09 '20 at 22:47
`-DCMAKE_BUILD_TYPE=Debug` when running cmake, `cmake --build /home/brian/sources/testStatckOverflow/cmake-build-debug --target testStatckOverflow -- -j 9` is the builld command. compiler is clang++, overall no optimizations to my knowledge. — Brian Yeh, Dec 09 '20 at 22:51
@PaulMcKenzie do optimizers optimize away memory leaks? never knew it could do that. — Brian Yeh, Dec 09 '20 at 22:54
@BrianYeh I believe compilers will eliminate calls to `new[]` if the resulting memory allocation has no effect on the program. See the [as-if rule](https://en.cppreference.com/w/cpp/language/as_if). In other words, those first few calls to `new[]` could be totally ignored by the compiler. — PaulMcKenzie, Dec 09 '20 at 23:04
[Clang at `-O2`](https://godbolt.org/z/KEhGjE) and above both eliminates the allocations and converts your recursive function into a loop, so you'll never see any memory growth or overflow your stack with recursive calls. — Miles Budnek, Dec 09 '20 at 23:28

score 0 · Answer 1 · answered Dec 09 '20 at 22:35

0

Programs are typically given virtual memory which can vastly exceed actual available memory, which might be why you're not seeing anything breaking when you dynamically allocate all that memory. That's a topic for your own research if you're interested, and there are also several SO questions about that same situation.

As for actually inducing a stack overflow: try putting arrays on the stack in your infinite recursion and not dynamically allocating them.

answered Dec 09 '20 at 22:35

niets

61
4

Added that into my question. It still never ends. – Brian Yeh Dec 09 '20 at 22:44
To specify I added a stack allocated array to the recursive call. – Brian Yeh Dec 09 '20 at 22:53
Not sure then. Running your code with the huge allocations aborts with a bad_alloc. Commenting out all the dynamic allocations and running it causes a stack overflow. Might you have optimizations turned on? When I turn them on, they remove all the unused variables and allocations and then it runs forever. – niets Dec 09 '20 at 22:54
I ran with `clang++ main.cpp` so nothing set. – Brian Yeh Dec 09 '20 at 22:59
@BrianYeh Now the thing is that you've got the stack overflow error with no optimizations -- in the real world, that program would have been compiled with optimizations turned on, thus you would be back to the program acting in a smart way. – PaulMcKenzie Dec 09 '20 at 23:15

Trying to deliberately induce memory leak and stackoverflow but not seeing memory grow or program slow computer down

1 Answers1