함수에서 malloc 사용후 free로 메모리 해제안해줘도 되지 않나

윗분들 말씀처럼 free 가 필요가 없습니다.

그리고 만약 실행이 되게 return 위로 free 를 올린다고 한다면

함수의 return 값으로 포인터를 받는곳에서는 해채된 주소의 포인터를

받게 되므로 segment fault 가 날껍니다.

그리고 여담이지만 malloc() 등으로 heap 영역에 할당한 동적메모리는

함수가 종료된다고 해채되는것이 아닙니다

함수내에서의 pointer 변수가 해체되는것을 착각하신듯 합니다.

heap 영역의 주소를 가르키는 지역변수가 사라진다고 해서

heap 영역에 할당한 메모리 영역이 해체되는것은 아니지요

물론 프로세서가 종료되면 모두 해체가 됩니다만...

- advanced -

정말인가요? 그럼 윈도 NT에서도 왜 메모리 누수를 확인하는 툴이 있는건가요?

RisaPapa님의 말씀에도 메모리 리크가 있는 프로그램을 fastcgi에서 쓸수 없다는 부분도 있었습니다.

전 이 부분이 의아하네요.

그럼 실행 순간이 짧은 프로그램이라면 메모리 누수에 대한 고민을 안해도 되는 것입니까?

예 안해도됩니다. 적어도 리눅스에서는 안해도 됩니다.

무한 루프문에서 큰 데이타 덩어리를 malloc 해 보시기 바랍니다.

좋은 운영체제들은 프로그램이 종료될때 해제를 해주는 군요.

그렇다고 해서 프로그램이 처리못한 일을 운영체제가 처리하게 하는 일은 바보같은 일인 것 같습니다. cjh님 말처럼 차라리 스크립트 언어를 사용하는게 낫겠네요.

그런데 akbar님의 이야기는 현재 사용하지 않는 공간들을 운영체제가 페이징을 잘 해준다는 이야기로 받아들여도 되는 것입니까? 또 무한 루프중에 계속 malloc을 실행한다는 것인가요 아니면 한번 malloc을 시켜두고 종료를 하지 않는다는 말이신가요? 장기적으로 운영체제의 페이징에 부담이 될 가능성은 없는 것인가요?

void func() {

std::auto_ptr kkk(new char[3323]);
}

C++라이브러리 사용 하는것이 가장 편합니다.

... 실 수 했네요... 급하게 올리다 보니....

배열을 자동 해제 할때는 boost라이브러리에 있는 라이브러리를 써야 하죠....array_ptr이었던가...

강컴에서 2판 번역서를 검색해서 목차를 확인해보면

Chapter 17 STL과 객체 지향 프로그래밍과의 결합
17.1 상속과 가상 함수의 사용
17.2 컨테이너 인스턴스에서의 "코드 비대화" 방지

이었던 것으로 기억합니다.

대부분의 code 는

Appendix C 예제에서 사용했던 STL include 파일
C.1 예제 17.1에서 사용한 파일

에 있습니다.

그림문자는 Accelerated C++ 에서도 나오는데 그 시작은 Bjarne Stroustrup 의 The C++ Programming Language 였다고 합니다.(읽어보지는 못했습니다만...)

Accelerated C++ 는 개념만 빌려왔지만 STL Tutorial & Reference Guide 2nd Edition 은 source 역시 가져온 것 같습니다.

제가 말을 정확하게 적지 못했네요.

그렇다고 해서 프로그램이 처리못한 일을 운영체제가 처리하게 하는 프로그래머는 바보같다고 생각합니다.

*질문자가 아는 정도라 가정하고 설명하겠습니다. 중수이상 분들은 이해를...

1.함수를 호출할때 함수내의 변수는 스택에 있습니다.(스택구조를아셔야죠)
2.malloc함수나 new 연산자로 메모리를 할당해주면 힙부분에 할당이 됩니다.
= 힙은 해제 되지 않습니다.

질문하신분의 코드가 틀린건 아니지만 '나쁜습관' 이죠.(이유는 리플이 많이 올라와있으니 참고하시고요)

OS 가 할당되었던 메모리를 반환하지만 저렇게 코딩하다 보면 나중에 큰 프로그램이나 데몬을 작성할땐 마치 잘돌아가다 이유없이 죽는것 처럼 보입니다.

질문하신분이 원하시는 코드는 이렇게 하는게 좋을것 같네요.(물론 다른방법도 있습니다.)

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

char *re_str(char *ptr); 

int main() { 
   char *p="We are the world !!!";  
   char *rev;

   rev = re_str(p);
   printf("%s\n",rev); 

   free(rev);
   return 0; 
} 

char *re_str(char *ptr) { 
   char *rev; 
   int i,j; 
    
   i=strlen(ptr)-1; 
   j=0; 

   rev=(char *)malloc(strlen(ptr)+1); 

   for ( ; i>=0; i--) { 
      rev[j]=*(ptr+i); 
      j++; 
   } 

   rev[j+1]='\0'; 

   return rev; 
} 

지금 하는 얘기는 당연히 금방 종료하는 프로그램을 말하는 거겠죠...?

아무튼, 저는 이 얘기가 마치...

어떤 어린이가 "엄마가 방 청소 해주니까 청소 안해도 되요."라고 말하는 것으로 들립니다.

뭐... 자기가 청소 안하니까 현명하다고 할 수는 있겠죠. :o

p.s. 제 생각엔 이것도 코딩 스타일이라고 생각합니다.

Windows 95/98/ME does not do this well. Also, NT has fragmentation
problem. So in Windows, you'd better clean up resources before
program exits.

출처는요?

프로그램이 종료할때는 OS가 자동으로 그동안 사용하던 메모리를 해재해 주는건 맞습니다.
하지만 윗글중에 malloc 을 무한 루프돌렸을때 os가 자동으로 메모리해재에 관여한다고 쓰신 글은 먼가 잘못 이해한 것이 아닌가 합니다.
예를 들어 10Mbyte를 100회 malloc했을때 문제가없는듯이 보이는건
단지 virtual memory heap만이 증가 했기 때문이고 물리메모리는 할당되지않죠. 하지만 malloc 한후에 거기에 데이터를 0xff등으로 초기화를 해주면 물리메모리가 할당되면서 실제 os의 사용가능한 메모리 량이 줄어들게 됩니다.
실행 시간이 짧은 프로그램은 해제 안하더라도 상관없지만 오랜 수행 예상이 되는 프로그램은 꼭 해제해줘야합니다.
이런 버그가 가장 잡기 힘듭니다.

아니면 제가 잘못 알고있었나요?
많은분들의 한말씀 부탁드립니다.

지나가다 읽었지만 너무 한쪽이 치우치신 생각이신것 같습니다..

어떠한 이유나 근거로 바보같다고 생각하시는지는 모르겠지만..

위에 다른님들 말씀처럼 저도 코딩스타일이라고 생각합니다...

다른 초고수님들이 제작하신 apache, mysql 과같은 프로그램들이..

종료시키면 현재 리소스를 cleanup하고 죽는지 궁금하단 생각이들었습니다..

좀 콕 찍어서 바보라고 치부하기엔.. 좀 스케일이 큰 안건이 아닌가싶습니다..

메모리만 처리해야하나요? fork Thread모두 청소해주고 죽어야지요 ㅡㅡa?

결론은.. 알고 한다 모르고한다.. 차이 코딩스타일의 차이이겠지요..

p.s 서버 프로그래밍만 주로하는 관계로 특별히 해제후 종료의 필요성을
느끼지 못했습니다. 지나가던길의 봤는데.. 가슴이 뜨끔하군요 ㅡㅡa

코딩 스타일일 수는 있겠지만 좋지 않은 스타일입니다.

물론 해당 코드가 어플리케이션 단위에서 동작하는 것이라면 OS 가 알아서 정리해 주겠지만,

나중에 리팩토링을 해서 그것의 성격이 바뀌었다고 생각해 보십시오.

'모든 리소스는 할당과 해제가 pair 로 분명히 짝지어져 있다' 라는 일관성이 없이는

나중에 코드를 정리하고 재배치 할 일이 생길때

'어떤 놈이 free() 를 하는지 안하는지' 트래킹도 힘들어지고 앗차하는 순간 실수 하기 쉽습니다.

지나치게 엄격해 보이는 코딩 스타일은 대개가 선배들이 실패를 발판삼아 뼈에 새겨놓은 것들이 많습니다.

'Code Complete' 나 'Writing Solid Code' 같은 책을 읽어보시길 권합니다.

참고로 'Unix Network Programming' 같은 책들의 예제가 해제를 안하는 이유는

그 코드의 목적이 '구현' 이 아니라 '설명' 이기 때문입니다.

필드에서 입문책의 예제와 같은 코드를 작성해서는 안되겠지요.

물론입니다. fork() 야 관리를 해야하는 자식 process가 아닌 이상 메모리가 달라지니 무관하지만 thread 는 청소해 주어야 합니다.

thread 청소를 안해줬는데 프로그램이 정상종료 한다면 운이 좋은 거겠지요.

저와 같이 일하는 팀에서 malloc을 한다음 해제를 안하는 생각을 가진 사람이 있다면
저는 그사람과 같이 일하고 싶은 생각이 들지 않을 것입니다.

이 문제는 "{" 를 어디에 두느냐와는 사뭇다른 코딩스타일 얘기입니다.

교과서, 학교 프로젝트도 아니고, 팀플레이를 해야하는 상황이라면, 구루만 혹은 자기가 코딩할 때만 알고 쓰는 것들은 최대한 배제해야합니다.

그사람이 아무리 뛰어나도 팀플레이해야하는 상황에서는 다른 사람과 co-work할 수 있느냐가 가장중요합니다.

liongo 님을 타박하는건 아니고,

단지 제가 해왔던 고민들을 적으면 도움이 되지 않을까 해서 긴 글을 적습니다.

저도 한때 liongo 과 같은 생각을 한 적이 있었습니다.

'현실' 을 인정하자는 것이었지요.

그렇게 프로그래머로서 오랜 시간을 지낸 뒤에 제 자신의 결과물을 뒤돌아 보았습니다.

결과는 제가 보기에도 부끄러웠습니다.

코드들은 지저분했고, 거기에는 또 이유가 주렁주렁 달려 있었습니다.

"이거 만들때는 시간이 부족했어."

"처음부터 계획이 무리였다구."

"이건 예제일 뿐이야" 등등.. 어쩔수 없었다는 이유들.

많은 프로그래머들이 쉽게 하는 말들입니다.

하지만 자존심은 있어서 제가 마음만 먹으면 그걸 제대로 할 수 있는 능력은 있다고 생각했었습니다.

그런데..

제가 보았던 많은 구루들은 단지 "만들때 운좋게 여유가 많이 주어졌던 사람들" 이었겠는가.. 하는데까지 생각이 미치더군요. 절대 그렇지 않겠지요.

결국 프로그래머는 자신이 뱉어내는 코드에 대해 모든것을 책임져야 한다는 것을 알았습니다.

그 후로 한번 쓰이고 말 예제 하나를 만들더라도 최선을 다하기 시작했습니다.

뭔가 도저히 사정이 안되어서 좋지않은 코드가 나올것 같다면.. 개발자가 해야할 일은 어떻게든 돌아가도록 코딩을 하는게 아니라 일단 코딩을 중단하고 바로 그 문제가 되는 환경을 개선하는 일이라고 생각합니다.

어려워 보이지만 해보니 의외로 쉽더군요.

도저히 말이 통할것 같지 않던 관리자들도 "이만큼의 시간이 주어지지 않으면 아예 결과를 내지 않겠다" 라고 땡깡을 부리니 어떻게든 시간을 만들어 주었습니다.

그 다음 일은 그렇게 주어진 조건 하에서 제가 할수 있는 최선을 다하는 것이었습니다.

그리고 저는 여유만 주어지면 괜찮은 코드를 만들 수 있을거라고 생각했던것이 큰 착각임을 알았었습니다.

얼마나 많은 자기반성과 공부가 필요한지...

저는 핑계와 합리화에 가려 제자신을 보지 못했던 것입니다.

지금도 제대로 아는것은 없습니다.

단지 다행인 점이라면 "무엇을 해야 하는지" 는 이제 보인다는 것이죠.

그리고 계속 노력 중입니다.

맞습니다. : D

위에 제가 쓴 글과 같이 저도 겪어보고 답변을 받아서 알게된 사실입니다.
그리고 책에 그렇게 쓰여있다고 그게 완벽하게 동작한다고 생각하시나요?
특히 소스도 볼 수 없는데도? 그렇게 완벽하면 왜 다운 잘되는 걸로 유명
하겠습니까?

그리고 당연히 Linux/Unix도 비슷한 문제가 있을 수 있습니다. 단지 덜
발생을 하더라 라는 것일 뿐이죠. 그리고 저는 윈도가 멍청하다고 한 적은
없습니다. 저런 문제가 있더라 하는 것이지요.

님은 윈도와 C++에 대해서 너무 민감하게 반응을 하시는 것 같습니다. :-)

다운이 되는 원인은 여러가지 이유가 있을수 있습니다

chuns님이 주장하시는것은 단지 ... 추측일뿐이라는 생각이 듭니다

[ 특히 98이하에서는 잘못된 OS 메모리 접근에 예외를 내지 않는 경우가
많습니다 , 이것이 98의 큰 약점이죠
단 프로세스간 메모리 접근은 예외를 냅니다 , 다운이 잦은 이유는
아마도 이러한 메모리 접근에 관한 부분일 확률이 매우 큽니다.
윈도우를 공부하셨다면 98이하의 약점이 뭔지 잘 아셨을텐데요
98이하는 다운 되는 이유가 , 프로세스가 리소스를 해제 못하는 이유라기보단 , 근본적인 다른 문제가 있는겁니다]

그리고 전 완벽하다고 한적은 없습니다

윈도우의 완벽히 공부했던 사람의 책 내용을 살펴보고 일반적으로 그렇게 돌아간다는 이야기를 한것뿐이죠

사실 printf에도 버그가 있을지 누가 압니까? 그런식으로 완벽을 주장하시면
버그 없는 프로그램은 존재하지 않습니다 ....

그리고 제가 했던
멍청하다는 말은 chuns님말을 듣고 밑에 분이, 영어로 "그럼 윈도우가 리눅스보다 멍청하다 "고 하셔서 한말입니다 오해는 없으시길를......

ㅎㅎ 그리고 .... 단편화하고 리소스 해제 하는거하고 무슨 연관이 있는지
모르겠네요

유닉스의 내부 책를 보면 메모리 할당 해제시
단편화는 리눅스나 유닉스도 똑같이 발생할수 있으며

모든 운영체제에서 이것을 특정 알고리즘으로 해결합니다

따라서 단편화에 관한 속도 차이는 메모리 관리를 어떤 알고리즘으로 하느냐에 따라 유닉스와 리눅스끼리도.... 차이가 많이 나게 됩니다

그리고 만약 속도가 유닉스가 더 빠르다면 , 속도를 위해 메모리를 더 희생했을 확률도 크고요

Buddy 알고리즘을 쓴다고 책에서 보았지만 , 그 실제 구현은 OS 벤더 마다 다를것입니다

[참고로 윈도우가 유닉스보다 오히려 늦게 나왔기때문에 더 좋은 알고리즘으로
구현했을수도 있습니다 , 동시대 윈도우와 유닉스를 비교했을 당시요,물론 추측이니다 :wink: ]

많은 알고리즘의 장단점이 있듯이, 장점이 있으면 단점이 있는법입니다

단지 MS에서 malloc free 많이 하면 단편화가 발생할수 있다는 말에...
윈도우가 더 후지다는 생각을 했다면.... OS책 한번 다시 보셔야 할거 같습니다

참 지금 책이 없어 확인은 못해보지만

제 기억으로는 리눅스나 유닉스는 힙메모리를 링크드리스트로 관리를 합니다

그리고 2배 단위로 메모리를 할당하기때문에 치명적인 내부 단편화를 유발할수 있습니다

예를 들면 1메가 할당에 1바이트라도있으면 1메가 할당을 위해
2메가를 할당해야합니다

그리고 링크드 리스트의 구조상 빠른 할당과 해제가 가능하지만

그 할당과 해제 시간의 간격이 커 .... 링크드리스트가 길어질수록
속도는 무지막지 저하 될것입니다

한마디로 모든 구조는 장단점이있습니다

윈도우의 힙 구조는 외부 단편화때문에 골머리를 썩는거 같더군요

그래서 디폴트 힙 말고도 다른 힙을 두어서 관리할수 있는 기법도 있습니다

메모리 free문제가 운영체제의 능력(?)으로 비약되고 있군요. :shock:

다시 질문하신분의 주제로 돌아가서
"free()하도록 하세요."라고 권고합니다.

메모리관리를 운영체제에 맡기는 패턴이 좋다고 생각하거나, 익숙하다면 개발툴을
C에서 메모리관리 필요없는 Java (JVM)이나, 아니면, 어떤 스크립트언어로 전향하는게 맞다고 생각하는 바입니다.