C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

자유게시판
세상 살아가는 이야기들을 나누는 사랑방입니다.
[13474] 메모리 리크 감시: ReportMemoryLeaksOnShutdown
박지훈.임프 [cbuilder] 8207 읽음    2007-10-23 04:29
Roland Beenhakker씨의 Delphi Power Unleashed 블로그에 델파이의 알려지지 않은 메모리 리크 검사 기능에 대한 글이 올라왔습니다.
http://beensoft.blogspot.com/2007/10/watch-your-memory.html

델파이 어느 버전부터, 델파이로 만든 애플리케이션의 메모리 리크를 간단히 체크해주는 기능이 추가되었다는 얘기입니다. 그렇게 사용하기 복잡한 것도 아니고, 단지 프로젝트 소스의 Application.Initialize; 바로 앞에 다음과 같이
ReportMemoryLeaksOnShutDown := true;
한 줄만 추가하면 된다는 것입니다.

예를 들어 제가 폼 하나만 달랑 있는 프로젝트에서 TForm.Create(nil); 이렇게 해버리면 폼 객체 하나가 리크되겠죠. 변수로 받지도 않았으니까요. 이런 경우에 프로그램을 종료하면 바로 다이얼로그가 떠서 친절하게 "리소스가 리크되었어요~" 하고 알려주는 겁니다. 실제로 다음과 같이 나옵니다.



폼 하나 리크되었는데 내용이 좀 많다 싶지만, 이 다이얼로그의 내용이 모두 폼 하나에서 생성된 리소스들입니다.
가장 아래줄에 TForm 자체도 나오고요.

소스를 뒤져보니, ReportMemoryLeaksOnShutDown 전역 변수는 System.pas에 있고, BDS 2006 버전부터 추가가 되었더군요. 따라서 BDS 2006과 델파이 2007을 사용하시는 분들은 이 기능으로 간단히 메모리 리크를 확인할 수 있습니다.

그런데, 이상하게도 C++빌더에서는 같은 방법으로 해도 컴파일이 안되는군요. 똑같이 System.hpp에 ReportMemoryLeaksOnShutDown 변수가 있는데, 못찾았다고 에러가 납니다. 다른 분 누군가가 한번 테스트해보고 알려주세요. ^^

그럼...
박지훈.임프 [cbuilder]   2007-10-23 04:35 X
C++빌더에서 컴파일이 안되는 이유는 알았습니다. 헤더에 생성된 ReportMemoryLeaksOnShutDown 변수의 철자 중 ShutDown을 Shutdown으로 써야 하는군요.

그런데 이상하게 컴파일하고 실행해도 C++빌더에서는 리크 레포팅 다이얼로그가 안나타나네요. 더 알아보겠습니다. ㅎㅎ
박지훈.임프 [cbuilder]   2007-10-23 04:45 X
fastMM의 기능이었군요. 그래서 2006 이상에서만 동작하는 거였습니다.
http://dn.codegear.com/article/33416

전에 봤던 문서인데 자세히 봐둘 걸..
평소에 공부 안한 놈이 꼭 이런 미련한 짓을 합니다.

ReportMemoryLeaksOnShutdown := DebugHook <> 0;
이런 식으로 코딩하면 디버깅 모드에서만 동작한다, 이런 코멘트도 있군요.

반드시 프로젝트 소스에서 할 필요는 없고, 소스의 원하는 위치에서 온오프시킬 수 있나봅니다.
박지훈.임프 [cbuilder]   2007-10-23 04:55 X
궁리를 해봐도 C++빌더에서 안될 별다른 이유가 없어보이는데..
아무래도 fastMM의 일부 기능이 C++빌더에선 적용이 안되는 게 아닌가 싶습니다.
김도완 [purplecofe2]   2007-10-23 09:53 X
full  debug mode라는 것도 있습니다.

만약 안된다면, http://fastmm.sf.net에서 4.78버전을 사용해보시는 것도.
Lyn [tohnokanna]   2007-10-23 09:54 X
음.. 얼마전에 델마당에서도 뜬 글이군요 `-`ㅋ
Lyn [tohnokanna]   2007-10-23 09:54 X
그런데 이거 제대로 해제 한 상태에서도 계속 릭이 생기던데..
VCL 자체에 릭이 있는건가요?
김도완 [purplecofe2]   2007-10-23 11:38 X
그건 어느 정도 봐줄만한 leak일겁니다.

윈도우즈 리소스릭은 이걸로도 잡기 힘들죠. 그래서 leak이 아니라고 판단하기 쉽습니다.

메모리릭만 주로 잡아주니 리소스릭은 주의해야. 만약 리소스를 클래스에 담아버리면 다르겠지만요.
양병규 [bkyang]   2007-10-23 14:28 X
저도 예전부터 FastMM을 쓰고 있었기때문에 익숙한 기능입니다만... 델파이의 System유닛에 보면 메모리매니져가 (INC파일로..)만들어져 있습니다만... 그 메모리매니져의 기능을 FastMM이 다시 만든거라고 보시면됩니다. 그래서 GetMem과 같이 델파이에서 메모리관리하는 함수들이 FastMM에서  만든 메모리매니저를 사용하게되져.. C++에서는 메모리관리하는 방식이 델파이하고는 다르기때문에.. 제 생각에는 FastMM은 델파이에서만 동작할것같습니다.(기회되면 2006이상 버전의 메모리매니져를 좀 봐야겠네여....)
박지훈.임프 [cbuilder]   2007-10-24 07:28 X
호... 저도 예전부터 FastMM에 대해 알고는 있었지만 그리 중요하게 여기지 않아서 미리 써보지 않았었는데, 그런 기능이 있었군요. 미리 알았음 좋았을 걸...

그런데 C++빌더에서도 FastMM이 적용 가능한 것 같고, 이미 2006 버전부터 적용되어 있는 거 같습니다. 왜냐하면, C++빌더에서는 예전부터 아예 메모리 매니저 dll(borlndmm.dll)을 RTL 개념으로 별도로 가지고 있었고 그걸 애플리케이션에서 dll로 동적 링크하거나 혹은 실행파일에 통합시킬 수 있었거든요. (델파이가 C++빌더보다 선택권이 적어서 아주 약간 아쉬웠던 부분입니다) 또 FastMM로 대체도 가능한 걸로 알고 있고, 여러 개발자들이 많이 (위에 글을 쓴 패패루님도) 그렇게 쓰고 있다고 들었습니다.
양병규 [bkyang]   2007-10-24 08:29 X
음... 그렇군요.... 저도 델파이가 되는게 C++빌더가안될리가 없는데...라고 생각은 했었습니다만....(근데 왜 빌더에서는 릭을 안보여줄까나..버근가부네...)
전에 한번 델파이의 메모리매니져 소스를 좀 보긴했는데... 어휴.... ^^; 어려버....--;
암튼.... 전 개인적으로 코드기어가 "Delphi"라는 이름을 좀 새로 바꾸고 주력 제품을 C++빌더로 옮겼으면 하는 바램입니다. 머....내실로는 별로 달라질게 없지만 영업적인면에서는 괜찮을것같은데....
박지훈.임프 [cbuilder]   2007-10-24 09:44 X
Delphi라는 이름에 대해서 저도 마찬가지 생각입니다.

뭔가 신비한 감을 주는 Delphi라는 이름이 내부 개발자 결속에는 많이 도움이 되었지만, 반대로 외부에서 바라보기에는 어떤 일반적인 프로그래밍 언어를 쓰는 하드코어 개발툴이라는 느낌보다는 파워빌더와 비교할 만한 케이스툴 정도의 느낌이 강하죠. 아마도 언어 이름이 제품명에 안들어간 탓이 클 거 같은데요.

VCL이 추가되고 RAD 기능이 추가되면서 이전까지 쓰던 '터보 파스칼', '볼랜드 파스칼'이라는 이름에서 이름을 바꿀 거였으면 더 느낌이 팍 오고 직관적인 이름이 좋았을텐데요. 뒤지다 뒤지다 다른 좋은 이름이 없었더라도, 차라리 MS를 따라간다는 느낌이 드는 한이 있어도, 쉽게 생각할 수 있는 '비주얼 파스칼' 정도가 나쁘지 않았을 거 같습니다.

그런데 저로서는, 예전에도 이 자유게시판에 두어번 투덜거린 적이 있습니다만, C++빌더라는 이름도 맘에 안듭니다! 역시 케이스툴 냄새가 풀풀 나요. 전통있고 많이 알려진 '볼랜드 C++'이란 좋은 이름을 왜 버리고 이름을 바꿔가지구...
이정구 [appleii]   2007-10-24 22:41 X
'비주얼 파스칼' 은 MS에서  만든 것으로 착각할 수 있으니.. (마케팅 측면에서는 더 유리하겠죠?) '래피드 파스칼' 이 좋지 않을까요? 터보 파스칼의 이름을 그대로 이어 나갔으면 더 좋았을 것이라는 생각을 해봅니다. Delphi 가 뭐냐고 묻는 사람은 많아도 터보 파스칼이 뭐냐고 묻는 사람은 없을 테니까요.

+ -

관련 글 리스트
13474 메모리 리크 감시: ReportMemoryLeaksOnShutdown 박지훈.임프 8207 2007/10/23
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.