1
votes

As conceptually stated, the stack grows down and the heap up; is there a point for both to collide? If yes, then does the "stack overflow" happen when the stack grows and crosses its limit? Can't it enter into the heap section?

The heap also grows upwards so its size is also fixed, I think. But nowhere is it mentioned how much memory is allocated for the heap. When I tried on my computer, both stack and heap memory addresses are going upward.

It's not clear conceptually for me.

1
What method did you use to determine that heap and stack addresses are going upward? You should include this code and the results that you got.Alain Merigot
I guess you're thinking about an image such as this one. This is pretty old nowdays, and modern paged and virtual memory operating systems doesn't work like that.Some programmer dude
@AlainMerigot, actually i created variable in both the place and print the address and got to knowTuhin Panda
@Someprogrammerdude,not only that pic, but there are lot place where same thing is mentioned. can you please clear my doubt about the stack and heap overlappingTuhin Panda
In the "old" days of DOS and whatnot, some operating systems allocated a fixed size chunk for each running program, and that chunk could not be extended. That's what you see in such an image. Today, the operating systems uses pages allocated from virtual memory, and then the pages can be mapped at any valid address. I suggest you do some more research about virtual memory and paging.Some programmer dude

1 Answers

0
votes

The stack grows accordingly to the platform. Look at this question for details.

Besides the direction when the stack grows, when you need to increase the stack size, the Memory Managers asks for a contiguos virtual memory block in the direction it has to grow, if that request can be satisfied, your stack grows, otherwise the request fails.

The failure is handled differently, according to hardware architecture, operating system, and configurations. For example, a standard user mode application on windows generally fails with a "not enough memory to execute the operation", but the failure could vary as corruption could occur.

Each thread is allocated a range of contiguous virtual addresses upon start. This value is decided in order by the compiler, which can be overridden by you and finally overriden by the operating system. You can smash a process by simply starting a sufficient number of threads without doing number (aside from handle exhaustion which is irrelevant here).