It seems stack-based variable not be released after function












-1















I'm new to C.



It is famous that variables in stack memory be released after function ends. But in my test, It not be released and memory occupies.



The example is clear:



#include <stdio.h>
#include <unistd.h>
#include <string.h>

void run() {
printf("Start test. Memory usage in task manager: 504KB n");
sleep(5);

char buf1[3145728];
memset(buf1, 'x', 3145728);
printf("buf1 Present. Memory usage in task manager: 3.9MB n");

sleep(10);
return;
}

int main() {
run();

printf("run() ends. But memory usage in task manager is still: 3.9MB n");
sleep(10);

char buf2[3145728];
memset(buf2, 'y', 3145728);
printf("buf2 Present. Memory usage in task manager: 7.0MB n");

sleep(15);
return 0;
}


I think, memory usage after run() function should be back to what was first, but it seems the variable not be released and stays in memory.



Am I wrong?



More details:




  • I wrote sleep to have time to look at Task Manager. Just because of that :-)


  • I have used lxtask in GNU/Linux to monitor memory usage. I'm used gcc compiler.











share|improve this question

























  • You are making assumptions upon things that aren't guaranteed by the standard. All definitions and statements other than sleep() and printf() can be optimized away since they have no part in the observable behaviour of your program.

    – Swordfish
    Nov 13 '18 at 6:59













  • sleep has no effect here, the compiler allocates auto memory before that. Maybe if it was a variable length array....

    – Jean-François Fabre
    Nov 13 '18 at 7:04











  • I wrote sleep to have time to look at Task Manager. Just because of that :-)

    – Ali Hardan
    Nov 13 '18 at 7:10











  • How did you check that memory was release or not? What is your platform?

    – Jabberwocky
    Nov 13 '18 at 7:14






  • 1





    Maybe the OS is doing a copy-on-write allocation for the big stack you're using. And this memory is not released so you can call run() over and over again without reallocation.

    – ulix
    Nov 13 '18 at 7:30


















-1















I'm new to C.



It is famous that variables in stack memory be released after function ends. But in my test, It not be released and memory occupies.



The example is clear:



#include <stdio.h>
#include <unistd.h>
#include <string.h>

void run() {
printf("Start test. Memory usage in task manager: 504KB n");
sleep(5);

char buf1[3145728];
memset(buf1, 'x', 3145728);
printf("buf1 Present. Memory usage in task manager: 3.9MB n");

sleep(10);
return;
}

int main() {
run();

printf("run() ends. But memory usage in task manager is still: 3.9MB n");
sleep(10);

char buf2[3145728];
memset(buf2, 'y', 3145728);
printf("buf2 Present. Memory usage in task manager: 7.0MB n");

sleep(15);
return 0;
}


I think, memory usage after run() function should be back to what was first, but it seems the variable not be released and stays in memory.



Am I wrong?



More details:




  • I wrote sleep to have time to look at Task Manager. Just because of that :-)


  • I have used lxtask in GNU/Linux to monitor memory usage. I'm used gcc compiler.











share|improve this question

























  • You are making assumptions upon things that aren't guaranteed by the standard. All definitions and statements other than sleep() and printf() can be optimized away since they have no part in the observable behaviour of your program.

    – Swordfish
    Nov 13 '18 at 6:59













  • sleep has no effect here, the compiler allocates auto memory before that. Maybe if it was a variable length array....

    – Jean-François Fabre
    Nov 13 '18 at 7:04











  • I wrote sleep to have time to look at Task Manager. Just because of that :-)

    – Ali Hardan
    Nov 13 '18 at 7:10











  • How did you check that memory was release or not? What is your platform?

    – Jabberwocky
    Nov 13 '18 at 7:14






  • 1





    Maybe the OS is doing a copy-on-write allocation for the big stack you're using. And this memory is not released so you can call run() over and over again without reallocation.

    – ulix
    Nov 13 '18 at 7:30
















-1












-1








-1








I'm new to C.



It is famous that variables in stack memory be released after function ends. But in my test, It not be released and memory occupies.



The example is clear:



#include <stdio.h>
#include <unistd.h>
#include <string.h>

void run() {
printf("Start test. Memory usage in task manager: 504KB n");
sleep(5);

char buf1[3145728];
memset(buf1, 'x', 3145728);
printf("buf1 Present. Memory usage in task manager: 3.9MB n");

sleep(10);
return;
}

int main() {
run();

printf("run() ends. But memory usage in task manager is still: 3.9MB n");
sleep(10);

char buf2[3145728];
memset(buf2, 'y', 3145728);
printf("buf2 Present. Memory usage in task manager: 7.0MB n");

sleep(15);
return 0;
}


I think, memory usage after run() function should be back to what was first, but it seems the variable not be released and stays in memory.



Am I wrong?



More details:




  • I wrote sleep to have time to look at Task Manager. Just because of that :-)


  • I have used lxtask in GNU/Linux to monitor memory usage. I'm used gcc compiler.











share|improve this question
















I'm new to C.



It is famous that variables in stack memory be released after function ends. But in my test, It not be released and memory occupies.



The example is clear:



#include <stdio.h>
#include <unistd.h>
#include <string.h>

void run() {
printf("Start test. Memory usage in task manager: 504KB n");
sleep(5);

char buf1[3145728];
memset(buf1, 'x', 3145728);
printf("buf1 Present. Memory usage in task manager: 3.9MB n");

sleep(10);
return;
}

int main() {
run();

printf("run() ends. But memory usage in task manager is still: 3.9MB n");
sleep(10);

char buf2[3145728];
memset(buf2, 'y', 3145728);
printf("buf2 Present. Memory usage in task manager: 7.0MB n");

sleep(15);
return 0;
}


I think, memory usage after run() function should be back to what was first, but it seems the variable not be released and stays in memory.



Am I wrong?



More details:




  • I wrote sleep to have time to look at Task Manager. Just because of that :-)


  • I have used lxtask in GNU/Linux to monitor memory usage. I'm used gcc compiler.








c performance memory memory-management memory-leaks






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 13 '18 at 7:20







Ali Hardan

















asked Nov 13 '18 at 6:44









Ali HardanAli Hardan

616




616













  • You are making assumptions upon things that aren't guaranteed by the standard. All definitions and statements other than sleep() and printf() can be optimized away since they have no part in the observable behaviour of your program.

    – Swordfish
    Nov 13 '18 at 6:59













  • sleep has no effect here, the compiler allocates auto memory before that. Maybe if it was a variable length array....

    – Jean-François Fabre
    Nov 13 '18 at 7:04











  • I wrote sleep to have time to look at Task Manager. Just because of that :-)

    – Ali Hardan
    Nov 13 '18 at 7:10











  • How did you check that memory was release or not? What is your platform?

    – Jabberwocky
    Nov 13 '18 at 7:14






  • 1





    Maybe the OS is doing a copy-on-write allocation for the big stack you're using. And this memory is not released so you can call run() over and over again without reallocation.

    – ulix
    Nov 13 '18 at 7:30





















  • You are making assumptions upon things that aren't guaranteed by the standard. All definitions and statements other than sleep() and printf() can be optimized away since they have no part in the observable behaviour of your program.

    – Swordfish
    Nov 13 '18 at 6:59













  • sleep has no effect here, the compiler allocates auto memory before that. Maybe if it was a variable length array....

    – Jean-François Fabre
    Nov 13 '18 at 7:04











  • I wrote sleep to have time to look at Task Manager. Just because of that :-)

    – Ali Hardan
    Nov 13 '18 at 7:10











  • How did you check that memory was release or not? What is your platform?

    – Jabberwocky
    Nov 13 '18 at 7:14






  • 1





    Maybe the OS is doing a copy-on-write allocation for the big stack you're using. And this memory is not released so you can call run() over and over again without reallocation.

    – ulix
    Nov 13 '18 at 7:30



















You are making assumptions upon things that aren't guaranteed by the standard. All definitions and statements other than sleep() and printf() can be optimized away since they have no part in the observable behaviour of your program.

– Swordfish
Nov 13 '18 at 6:59







You are making assumptions upon things that aren't guaranteed by the standard. All definitions and statements other than sleep() and printf() can be optimized away since they have no part in the observable behaviour of your program.

– Swordfish
Nov 13 '18 at 6:59















sleep has no effect here, the compiler allocates auto memory before that. Maybe if it was a variable length array....

– Jean-François Fabre
Nov 13 '18 at 7:04





sleep has no effect here, the compiler allocates auto memory before that. Maybe if it was a variable length array....

– Jean-François Fabre
Nov 13 '18 at 7:04













I wrote sleep to have time to look at Task Manager. Just because of that :-)

– Ali Hardan
Nov 13 '18 at 7:10





I wrote sleep to have time to look at Task Manager. Just because of that :-)

– Ali Hardan
Nov 13 '18 at 7:10













How did you check that memory was release or not? What is your platform?

– Jabberwocky
Nov 13 '18 at 7:14





How did you check that memory was release or not? What is your platform?

– Jabberwocky
Nov 13 '18 at 7:14




1




1





Maybe the OS is doing a copy-on-write allocation for the big stack you're using. And this memory is not released so you can call run() over and over again without reallocation.

– ulix
Nov 13 '18 at 7:30







Maybe the OS is doing a copy-on-write allocation for the big stack you're using. And this memory is not released so you can call run() over and over again without reallocation.

– ulix
Nov 13 '18 at 7:30














1 Answer
1






active

oldest

votes


















3














First don't trust task manager too much. It's not very accurate.



Another thing is that the compiler has an allocation strategy that is not completely known to you.




It is famous that variables in stack memory be released after function ends.




Which is "famous" is that you should not create a reference on a local variable and store/return it with a chance that it's used out of scope.



If you loop on that function, or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase.



That's because the compiler run-time won't automatically resize the stack down. It just keeps it allocated for the next time (it's the difference between stack size and capacity). There is no "memory leak". You can even configure executable (at link stage, and on Windows with tools like EDITBIN) to pre-allocate all the stack at startup to avoid resize and memory moves.






share|improve this answer


























  • Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

    – Ali Hardan
    Nov 13 '18 at 7:47











  • don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

    – Jean-François Fabre
    Nov 13 '18 at 9:31











  • Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

    – Ali Hardan
    Nov 13 '18 at 14:49











  • If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

    – Ali Hardan
    Nov 13 '18 at 23:47











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53275254%2fit-seems-stack-based-variable-not-be-released-after-function%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














First don't trust task manager too much. It's not very accurate.



Another thing is that the compiler has an allocation strategy that is not completely known to you.




It is famous that variables in stack memory be released after function ends.




Which is "famous" is that you should not create a reference on a local variable and store/return it with a chance that it's used out of scope.



If you loop on that function, or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase.



That's because the compiler run-time won't automatically resize the stack down. It just keeps it allocated for the next time (it's the difference between stack size and capacity). There is no "memory leak". You can even configure executable (at link stage, and on Windows with tools like EDITBIN) to pre-allocate all the stack at startup to avoid resize and memory moves.






share|improve this answer


























  • Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

    – Ali Hardan
    Nov 13 '18 at 7:47











  • don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

    – Jean-François Fabre
    Nov 13 '18 at 9:31











  • Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

    – Ali Hardan
    Nov 13 '18 at 14:49











  • If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

    – Ali Hardan
    Nov 13 '18 at 23:47
















3














First don't trust task manager too much. It's not very accurate.



Another thing is that the compiler has an allocation strategy that is not completely known to you.




It is famous that variables in stack memory be released after function ends.




Which is "famous" is that you should not create a reference on a local variable and store/return it with a chance that it's used out of scope.



If you loop on that function, or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase.



That's because the compiler run-time won't automatically resize the stack down. It just keeps it allocated for the next time (it's the difference between stack size and capacity). There is no "memory leak". You can even configure executable (at link stage, and on Windows with tools like EDITBIN) to pre-allocate all the stack at startup to avoid resize and memory moves.






share|improve this answer


























  • Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

    – Ali Hardan
    Nov 13 '18 at 7:47











  • don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

    – Jean-François Fabre
    Nov 13 '18 at 9:31











  • Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

    – Ali Hardan
    Nov 13 '18 at 14:49











  • If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

    – Ali Hardan
    Nov 13 '18 at 23:47














3












3








3







First don't trust task manager too much. It's not very accurate.



Another thing is that the compiler has an allocation strategy that is not completely known to you.




It is famous that variables in stack memory be released after function ends.




Which is "famous" is that you should not create a reference on a local variable and store/return it with a chance that it's used out of scope.



If you loop on that function, or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase.



That's because the compiler run-time won't automatically resize the stack down. It just keeps it allocated for the next time (it's the difference between stack size and capacity). There is no "memory leak". You can even configure executable (at link stage, and on Windows with tools like EDITBIN) to pre-allocate all the stack at startup to avoid resize and memory moves.






share|improve this answer















First don't trust task manager too much. It's not very accurate.



Another thing is that the compiler has an allocation strategy that is not completely known to you.




It is famous that variables in stack memory be released after function ends.




Which is "famous" is that you should not create a reference on a local variable and store/return it with a chance that it's used out of scope.



If you loop on that function, or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase.



That's because the compiler run-time won't automatically resize the stack down. It just keeps it allocated for the next time (it's the difference between stack size and capacity). There is no "memory leak". You can even configure executable (at link stage, and on Windows with tools like EDITBIN) to pre-allocate all the stack at startup to avoid resize and memory moves.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 13 '18 at 6:56

























answered Nov 13 '18 at 6:50









Jean-François FabreJean-François Fabre

102k954110




102k954110













  • Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

    – Ali Hardan
    Nov 13 '18 at 7:47











  • don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

    – Jean-François Fabre
    Nov 13 '18 at 9:31











  • Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

    – Ali Hardan
    Nov 13 '18 at 14:49











  • If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

    – Ali Hardan
    Nov 13 '18 at 23:47



















  • Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

    – Ali Hardan
    Nov 13 '18 at 7:47











  • don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

    – Jean-François Fabre
    Nov 13 '18 at 9:31











  • Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

    – Ali Hardan
    Nov 13 '18 at 14:49











  • If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

    – Ali Hardan
    Nov 13 '18 at 23:47

















Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

– Ali Hardan
Nov 13 '18 at 7:47





Thank you. Why in the main() operations in example which right afterwards run() function, increase memory, but functions after run() not?

– Ali Hardan
Nov 13 '18 at 7:47













don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

– Jean-François Fabre
Nov 13 '18 at 9:31





don't think like C interprets the instructions or declarations like you're reading them. For instance, it's not because you declare your array in the middle of your program that it will be allocated after sleep. You can be sure that there's no bug in the compiler memory-wise, or noone could use it. Your case isn'"t a nominal case. I suggest that you call run in a loop, you won't see stack increasing.

– Jean-François Fabre
Nov 13 '18 at 9:31













Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

– Ali Hardan
Nov 13 '18 at 14:49





Thank you. I have tested loop, You are right. but my question is: you have said or create another function that eats roughly the same amount of stack (or less) and you call it right afterwards, you'll notice that the memory does not increase. I have crated that function, and I won't see stack increasing, as you said. but Why when I create buffer in main() it increase stack, and when create buffer in other function than run(), not stack increase?

– Ali Hardan
Nov 13 '18 at 14:49













If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

– Ali Hardan
Nov 13 '18 at 23:47





If you can, please introduce a reference for this Q/A page (When compiler releases the memory and when keep it allocated?) . If the reference be a book, will be better.

– Ali Hardan
Nov 13 '18 at 23:47


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53275254%2fit-seems-stack-based-variable-not-be-released-after-function%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Florida Star v. B. J. F.

Danny Elfman

Lugert, Oklahoma