Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: 'deleaker'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. Deleaker 도움말 중 C++빌더에서 사용하는 방법을 번역했습니다. 관련 자료: 원문 보기, 델파이와 C++빌더 에서 메모리 누수 탐지하기 비디오 (한국어 더빙, 11min) 보기 구입 문의: 데브기어 도입 이 튜토리얼은 C++빌더 안에서 바로 메모리 누수를 감지하는 방법을 설명한다. 또한 누수를 일으키는 소스 사이를 이동하는 방법과 누수를 일으키는 스냅샷을 이용하여 어떻게 소스를 찾는 지를 설명한다. RAII, 스마트 포인터 등 현대식 기술들을 사용함에도 불구하고, 메모리 누수는 여전히 발생될 수 있다. malloc, calloc, new, delete 등 메모리 할당을 직접하는 코드를 사용하지 않더라도 마찬가지이다. 예를 들어, 스마트 포인터의 순환 참조는 누수를 발생시킨다. 오래된 프로젝트의 오래된 코드는 현대식 C++로 다시 작성할 수 없는 것이 일반적이며 이와 동시에 메모리 누수가 발생하므로 즉시 수정해야한다. 설치 딜리커(Deleaker)는 독립형 메모리 프로파일러로 실행할 수도 있고, C++빌더에서 플러그인으로 실행할 수도 있다. 누수가 고객의 장비에서는 재현이 되지만, 개발자의 장비에서는 재현되지 않는 경우가 있는데, 독립형 Deleaker는 이런 경우에 사용한다. 개발을 진행하는 동안 매일 사용하려면 Deleaker를 C++빌더에 플러그인한다. Deleaker가 일단 C++빌더에 플러그인으로 설치되고 나면, 개발자는 C++빌더 안에서 메모리 스냅샷을 찍고, 디버깅하면서 메모리 누수를 바로 찾을 수 있다. Deleaker는 C++빌더 2010 버전과 그 이후의 모든 버전에 플러그인 될 수 있다. 만약 C++빌더 6.0 버전을 사용하고 있다면 독립형 Deleaker를 사용하여 메모리 누수를 파악하기 바란다. Deleaker는 C++빌더에 설치될 때 , 컴퓨터에 이미 설치되어 있는 C++빌더 버전 중에 플러그인 될 수 있는 버전을 인식하고, 해당 버전에 플러그인 된다. Deleaker를 설치하고 나서 RAD 스튜디오를 실행하면, 메인 메뉴에 Deleaker 항목이 새로 추가된 것을 볼 수 있다. Deleaker를 열려면, 메인 메뉴 > Deleaker > Deleaker Window를 클릭한다. Deleaker 활성화가 디펄트 설정이므로, 메모리 누수를 바로 프로파일링할 수 있다. Deleaker를 비활성화/활성화 하려면 Deleaker > Enabled 를 사용한다. 그림1. C++빌더에 들어간 Deleaker 메뉴 메모리 누수 추가 폼 하나에 버튼 하나만 있는 간단한 윈도우 VCL 애플리케이션을 만든다. 이 버튼의 OnClick 이벤트에 다음 코드를 사용한다. void __fastcall TForm1::Button1Click(TObject *Sender) { int* p = new int[1024]; } 프로젝트 설정 Deleaker는 (무엇을 이용하여 어떻게 만들었는 지와 관계없이) 어떠한 애플리케이션도 프로파일링 할 수 있지만, 보다 많은 것을 포함하는 결과를 얻으려면 프로젝트 옵션을 설정하는 것이 더 좋다. 디버그 정보 디버그 정보를 생성하도록 지정하는 것이 가장 중요하다. 디버그 정보는 Deleaker가 주소를 해석하여 (예: 해당 주소에 상응하는 소스 파일 경로와 줄 번호) 메모리 누수가 발생되는 위치를 개발자가 손쉽게 이해할 수 있도록 한다. 디버그 정보 생성을 활성화하려면, 메인 메뉴 > Project > Options...를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > C++ Compiler > Debugging 항목을 선택한 후 Debug information 과 Debug line number information 모두 True를 선택한다. Enable Codeguard는 False를 선택하는 것이 좋다. 그림2. C++빌더에서 컴파일러가 디버그 정보를 생성하도록 설정하기 링커에서도 전체 디버그 정보를 생성하도록 하려면 Building > C++ Linker 항목을 선택한 후 Full debug information에서 True를 선택한다. 그림3. C++빌더에서 링커가 전체 디버그 정보를 생성하도록 설정하기 만약 명령줄을 사용하여 프로젝트를 빌드하는 경우, -v와 -y 옵션을 사용한다. 스택 ( Stack ) 프레임 생성 메모리가 할당될 때, Deleaker 고리는 콜 스택을 저장한다. Deleaker가 모든 호출자에 대한 정보를 얻으려면 스택 프레임이 필요하다. 스택 프레임 생성을 활성화하려면, 메인 메뉴 > Project > Options를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > C++ Compiler 를 선택한 후 General Compilation > Standard stack frames 항목에서 True를 선택한다. 그림4. C++빌더에서 스택 프레임을 활성화하기 만약 명령줄을 사용하여 프로젝트를 빌드하는 경우, -k 옵션을 사용한다. 최적화 비활성화하기 Deleaker는 어떤 실행파일에서도 메모리 누수를 탐지할 수 있다. 빌드 구성이 어떻든지 관계없이 탐지하지만, 메모리 할당과 관련된 보다 정확하고 명확한 정보를 얻으려면 모든 최적화 옵션을 비활성화하는 것이 더 좋다. 메인 메뉴 > Project > Options...를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > C++ Compiler > Optimizations 항목을 선택한 후 Disable all optimizations 항목에서 True를 선택한다. 그림5. C++빌더에서 최적화 비활성화하기 메모리 누수 파악하기 Deleaker가 메모리 누수에 대하여 최대한 많은 정보를 수집할 수 있도록 프로젝트 옵션을 설정하고나면, 빌드하고 실행한다. 앞에서 만든 폼 하나에 버튼 하나가 있는 애플리케이션이 나타나면 버튼을 클릭하여 메모리 누수를 만들고 나서 폼을 닫아서 종료한다. Deleaker가 활성화되어 있다면, 해당 폼을 실행하던 프로세스가 나갈 때 Deleaker는 스냅샷을 찍는다. 여기에는 해제되지 않은 모든 메모리 할당이 들어가는데, 이런 할당이 소위 메모리 누수이다. 앞에서 일부러 만든 누수의 결과는 아래 그림과 같다. 그림6. 스냅샷 찍기와 그 결과 누수를 일으키는 코드로 이동하려면 할당 항목을 더블클릭하거나 콜 스택 항목 중 하나에서 오른쪽 클릭을 하고 Show Source Code를 선택한다. C++ Builder에 해당되는 소스 파일이 열리고 누수를 일으키는 곳의 코드가 보인다. 그림7. 누수를 일으키는 소스 코드로 이동하기 영속하는 메모리 누수 수정하기 프로세스가 사용하는 메모리가 점점 더 많아진다는 것을 알게 되는 경우가 때때로 있다. 코드 중에 메모리를 가져오는 특정 부분이 계속해서 호출되고 있을 수 있다. 이런 동작이 의도한 바 일 수도 있고 아닐 수도 있지만, 어떤 경우라도 개발자는 이런 코드의 위치를 찾아내야 한다. Deleaker 창에서 바로 메모리 사용을 볼 수 있다는 점을 알아두면 좋다. 디버깅 중에 Resource Usage Graph로 가면 아래와 같은 화면이 보인다. 그림8. Deleaker의 리소스 사용 그래프 영속적인 메모리 누수를 만드는 코드를 추가해보자. 폼에 타이머를 하나 올리고, 이것을 활성화한다. Interval을 500ms로 설정하고 이 타이머의 OnTimer 이벤트에서 메모리 할당을 하자. void __fastcall TForm1::Timer1Timer(TObject *Sender) { int* p = new int[1000000]; } 프로젝트를 빌드하고 실행한다. 해당 프로세스가 실행되도록 그대로 둔 채로, Deleaker로 와서 Take Snapshot을 클릭한다. 현재 할당된 메모리와 기타 리소스가 보일 것이다. Hit Count 열을 보자. 여기에는 동일한 위치에 동일한 호출자가 만든 할당의 갯수가 표시된다. 따라서 동일한 곳에서 매우 많이 할당이 발생하는 리소스가 무엇인지, 그리고 Hit Count의 숫자를 통해 그 횟수가 얼마인지를 쉽게 식별할 수 있다. 즉 Hit Count는 영속적인 메모리 누수를 수정할 때 도움이 된다. 그림9. 스냅샷 찍기와 Hit Count 보기 이렇게 꾸준하게 누수되는 리소스를 탐지하는 또 다른 방법이 있다. 스냅샷 두개를 찍고 서로 비교하면, 각 스냅샷이 찍힌 시점들 사이에 발생한 메모리 할당만 볼 수 있다 (예: 꾸준하게 발생한 메모리 할당 축적). 스냅샷을 비교하려면 첫번째 스냅샷을 선택하고, 그 옆에 있는 Compare with...를 클릭하여 두번째 스냅샷을 선택한다. 그러면 Deleaker가 이 두개의 스냅샷 사이에 달라진 것만 계산한다. 그림10. 스냅샷 비교하기 VCL 오브젝트 누수 C++빌더 코드는 거의 항상 VCL 오브젝트를 생성하고 사용한다. 개발자는 자신이 직접 생성한 오브젝트를 명시적으로 제거해야 하는데 깜빡하고 놓치기 쉽다. C++빌더로 개발한다면 이런 오브젝트 누수가 아마도 가장 흔할 것이다. Deleaker가 이런 오브젝트 목록을 제공하는 이유가 바로 이것 때문이다. 이런 오브젝트를 살펴보려면 Delphi Objects 탭으로 이동한다. 오브젝트는 클래스 별로 그룹핑되어 있다. 각 클래스 별로 해당 오브젝트가 목록으로 표시되고, 각 오브젝트 별로 콜 스택이 표시된다. 각 클래스에는 생성된 오브젝트의 갯수와 전체 크기가 표시되므로, 가장 큰 것을 찾을 수 있다. 특정 클래스에 해당되는 오브젝트를 빠르게 찾으려면 Filter by name을 사용한다. 클래스 이름을 타이핑하기 시작하면 해당되는 클래스만 표시된다. 그림11. 살아있는 VCL 오브젝트 잡기와 클래스 이름으로 델파이 클래스 필터링하기 결론 메모리 누수 탐지는 간단한 작업이 아니다. 코드가 아무리 깔끔하고 개발자가 현대식 C++ 표준을 잘 따르는 경우에도 마찬가지이다. C++빌더로 작성된 코드는 VCL 오브젝트를 사용하는 경향이 많은데 이 VCL 오브젝트들은 전통적으로 할당과 해제 모두 명시적이어야 한다. 실수로 누수가 발생하기 쉽다. 이런 이유 때문에 Deleaker와 같은 메모리 프로파일러는 요즘 모든 개발자들에게 매우 중요한 도구이다. Deleaker는 C++빌더 안에 완전히 통합된다. 따라서 메모리, VCL 오브젝트, GDI 리소스 등의 할당을 편안하게 탐색할 수 있다. Deleaker는 범용 메모리 누수 탐지 도구이므로 윈32, 윈64 애플리케이션 모두를 대상으로 할 수 있고 전통적인 VCL 뿐만 아니라 파이어몽키 등 현대식 프레임워크를 모두 지원한다.
  2. Deleaker 도움말 중 델파이에서 사용하는 방법을 번역했습니다. 관련 자료: 원문 보기, 델파이와 C++빌더 에서 메모리 누수 탐지하기 비디오 (한국어 더빙, 11min) 보기 구입 문의: 데브기어 델파이 에서 메모리 누수를 찾는 방법 이 튜토리얼은 델파이(Delphi)로 작성된 애플리케이션에서 메모리 누수와 기타 리소스 누출을 감지하는 방법을 설명한다. 딜리커(deleaker)는 독립형 애플리케이션 또는 RAD 스튜디오에 플러그인으로 실행할 수 있다. 예를 들어 RAD 스튜디오가 없는 곳에서는 Deleaker를 독립형으로 실행할 수도 있어서 편하다. Deleaker를 RAD 스튜디오에서 플러그인으로 실행하면, 개발자가 RAD 스튜디오를 떠나지 않고 바로 누출을 검색할 수 있고, 발생 가능한 오류의 근원으로 더 빠르게 이동할 수 있다. Deleaker를 RAD 스튜디오에 설치하면, RAD 스튜디오의 메인 메뉴에 Deleaker 항목이 새로 추가된다. 그림1. 델파이에 들어간 Deleaker 메뉴 Deleaker 창을 열려면, 메인 메뉴 > Deleaker > Deleaker Window를 클릭한다. 그림2. 델파이에서 표시되는 Deleaker 창 메모리 누수 추가 폼 하나에 버튼 하나만 있는 간단한 애플리케이션을 만든다. 이 버튼을 클릭하면 메모리 할당과 오브젝트 생성이 되도록 한다. procedure TForm1.Button1Click(Sender: TObject); var p: Pointer; StringList: TStringList; begin GetMem(p, 42); StringList := TStringList.Create; end; 프로젝트 설정 누출에 대한 정보를 가장 신뢰할 수 있게 그리고 완벽하게 얻으려면 프로젝트 옵션을 설정해야 한다. 디버그 정보 활성화 가장 먼저, 컴파일러와 링커가 디버그 정보를 생성하도록 지정해야 한다. Deleaker는 이 정보에 따라 소스 코드가 있는 파일과 이에 대응하는 콜 스택 상의 주소를 연결할 수 있다. 컴파일러의 옵션: 디버그 정보를 생성하려면, 메인 메뉴 > Project > Options를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > Delphi Compiler > Compiling 항목을 선택한 후 Code generation > Debug information 항목에서 Debug information을 선택한다. 링커의 옵션: 디버그 정보를 생성하려면, 메인 메뉴 > Project > Options를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > Delphi Compiler > Linking 항목을 선택한 후 Debug information 항목에서 True를 선택한다. 그림3. 델파이에서 컴파일러와 링커가 디버그 정보를 생성하도록 설정하기 만약 명령줄을 사용하여 프로젝트를 빌드하는 경우, -V 옵션을 주면 컴파일러에서 디버그 정보를 생성한다. 스택 ( Stack ) 프레임 생성 컴파일러가 스택 프레임을 생성하도록 하는 것이 좋다. Deleaker는 스택 프레임이 없이 빌드된 경우에도 어떤 코드와도 작업을 할 수 있다. 하지만, 만약 코드가 스택 프레임을 사용하여 컴파일되면 콜 스택 관련 정보의 완성도가 더 높다. 스택 프레임을 활성화하려면, 메인 메뉴 > Project > Options를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > Delphi Compiler > Compiling 항목을 선택한 후 Code generation > Stack frames 항목에서 True를 선택한다. 그림4. 델파이에서 스택 프레임을 활성화하기 만약 명령줄을 사용하여 프로젝트를 빌드하는 경우, -$W+ 옵션을 주어야 스택 프레임을 생성한다. 최적화 비활성화하기 누수에 대한 보다 완전하고 정확한 정보를 얻으려면 최적화를 비활성화 한다. 메인 메뉴 > Project > Options를 클릭하면 표시되는 프로젝트 옵션 화면에서, Building > Delphi Compiler > Compiling 항목을 선택한 후 Code generation > Optimization 항목에서 False를 선택하고, Debugging > Use debug .dcus 항목에서 True를 선택한다. 그림5. 델파이에서 최적화 비활성화하기 만약 명령줄을 사용하여 프로젝트를 빌드하는 경우, -$O- 옵션을 주어야 최적화가 비활성화 된다. 스냅샷 찍기 디버깅을 시작하고 버튼을 클릭한다. RAD 스튜디오로 돌아가서 메인 메뉴 > Deleaker > Deleaker Window를 클릭하면 표시되는 Deleaker 창에서 Take Snapshot을 클릭하면, 메모리, 핸들, GDI 리소스, 오브젝트 등 할당된 리소스의 목록을 얻을 수 있다. 그림6. 스냅샷 찍기 각 리소스 별로 해당 콜 스택을 점검하여 코드의 어느 부분에서 리소스가 할당되었는지를 파악할 수 있다. 해당 소스 파일과 줄을 감지할 수 있는 경우 더블 클릭 (또는 컨텍스트 메뉴)를 사용하면 델파이의 코드 에디터가 열린다. 그림7. 누수를 일으키는 소스 코드로 이동하기 델파이 오브젝트 목록 획득하기 Delphi Objects 탭 안의 오브젝트는 클래스 별로 그룹핑되어 있다. 각 클래스 별로 해당 오브젝트가 목록으로 표시된다. 각 오브젝트 별로 콜 스택이 표시된다. 그림8. 살아있는 델파이 오브젝트 잡기 클래스를 빠르게 찾으려면 Filter by name을 사용한다. 클래스 이름을 타이핑하기 시작하면 해당되는 클래스만 표시된다. 그림9. 클래스 이름으로 델파이 클래스 필터링하기 누수 목록 획득하기 애플리케이션을 나가면, Deleaker가 자동으로 스냅샷을 생성하여 누수 목록 (예: 할당되었으나 해제되지 모든 리소스)을 제공한다. 개발자는 각 할당과 각 오브젝트의 콜 스택을 살펴보고 해당 리소스를 명시적으로 해제 (Free) 할 것인지를 결정할 수 있다. 그림10. 프로세스를 빠져나가면 스냅샷이 찍힌다. 프로세스가 점점 더 많은 메모리를 소비하는 경우에는 어떻게 할까? 이 경우, 프로세스가 소비하는 메모리가 꾸준하게 증가한다. 핸들(handle) 갯수 또는 GDI 오브젝트의 갯수가 증가하는 다른 경우도 있다. 그림11. Deleaker의 리소스 사용 그래프 누수를 발생시키는 원천을 어떻게 식별하는 지 살펴보자. 예를 들어, 타이머 하나를 추가하여 정기적으로 메모리를 할당한다. procedure TForm1.Timer1Timer(Sender: TObject); var p: Pointer; StringList: TStringList; begin GetMem(p, 42); StringList := TStringList.Create; end; 첫번째: 히트 카운트 (Hit Count)에 신경쓰기 Deleaker는 모든 누수를 해당 콜 스택 별로 그룹핑한다. 동일한 콜 스택을 공유하는 누수의 갯수는 Hit Count 열에 나타난다. 따라서, 만약 메모리가 꾸준하게 동일한 곳에서 할당된다면, Hit Count가 계속 증가하게 된다. 만약 동일한 클래스의 오브젝트가 꾸준하게 생성된다면, Delphi Objects 탭에 있는 Object Count 열의 숫자가 증가하게 된다. Hit Count와 Object Count를 내림차순으로 정렬하면 문제되는 코드의 지점을 빠르게 찾을 수 있다. 그림12. 리소스 사용가 꾸준하게 증가하면, Hit Count와 Object Count를 내림차순으로 정렬하여 빠르게 파악할 수 있다. 두번째: 연속된 스냅샷 사이의 차이점 파악하기 하지만, Hit Count와 Object Count를 내림차순으로 정렬하기는 "쌓이는" 리소스를 숨길 수 없다. 꾸준하게 누수되는 리소스 만을 보는 또 다른 방법이 있다. 먼저, 기본 스냅샷을 찍는다. 그리고 나서 프로세스가 더 많은 리소스를 할당할 수 있는 시간을 준다. 이렇게 스냅샷 두개가 있으면 우리는 기준 스냅샷이 찍힌 후에 할당된 리소스에만 신경을 쓸 수 있다. 기준 스냅샷을 선택하고 Compare with...를 클릭하고 두번째 스냅샷을 선택한다. 그러면 Deleaker가 이 두개의 스냅샷 사이에 달라진 것만 계산한다. 가끔 스냅샷을 비교한 결과 목록이 비어있다. 이 경우, 모든 필터를 제거하면 모든 할당을 예외없이 볼 수 있다. 결과 목록이 더 깔끔해진다. 그림13. 스냅샷 비교하기 필터 Deleaker는 당신의 프로그램이 만든 누수 만을 보여주려고 노력하고 그 외의 것들은 필터링한다. 예를 들어, 시스템 라이브러리 또는 다른 코드에 의해 할당된 메모리 같은 것은 보여주지 않는다. 만약 프로세스에서 할당한 모든 리소스가 보여지면 그 중 어느 것이 당신의 애플리케이션 코드에 해당되는 것인지를 파악하기가 어려울 것이다. 개발자들에게 일부 누수가 숨김 처리되었음을 알려주기 위해 Deleaker는 Filters 버튼 오른쪽에 숨겨진 누수와 표시된 누수의 갯수를 보여준다. 이 버튼을 이용하면 필터를 끄거나 켤 수 있다. 그림14. 할당 필터링 필터는 3가지 유형이 있다. Hide leaks with no source code - Deleaker가 소스 코드를 찾지 못하는 누수를 숨긴다. Hide leaks from excluded modules - 제외된 모듈 즉 Options > Exceptions > Excluded Modules 에 지정된 모듈의 코드에서 만드는 누수를 숨긴다. 디펄트 설정에서는 시스템 라이브러리들이 해당된다. Hide known leaks - 아마 알려진 희망이 없는 누수를 숨긴다: 피하거나 고칠 수 없는 것들이다. 예를 들어 표준 라이브러리에 의한 일회성 메모리 할당 등이 여기에 해당된다. Options > Exceptions > Known Leaks 에서 이런 누수들의 목록을 찾을 수 있다.
  3. 원본: Catching memory leaks in Delphi: a definitive list of tools - 2020년 5월 18일, Wagner Landgraf 메모리 누수 감지는 델파이 개발에서 매우 중요한 작업이다. 이 점에 대해서는 "메모리 누수가 무엇이고 어떤 결과를 초래하는가?" 에서 TMS XData로 만든 서버 등 서버 애플리케이션에서는 더욱 중요하다는 점을 강조하면서 설명했던 적이 있다. 곧 출시될 델파이 10.4 버전에서는 작년에 약속한 대로 통합 메모리 관리가 실현되어 출시될 것으로 보인다. 그래서 이 글이 더욱 의미가 커졌다. 인생이 그렇듯이 변화란 100% 좋거나 100% 나쁘지 만은 않다. 10.4 버전부터 반영된 통합 메모리 관리 역시 장단점이 있다. 다만 한 가지 사실은 분명하다. 델파이의 메모리 관리 방식이 이제 모든 플랫폼에서 동일하다. 따라서 메모리 누수 감지 방법 역시 모든 플랫폼에서 더욱 유사해졌다. 개인적으로는 좋은 변화라고 생각한다. 이 변화가 모바일 플랫폼에서 "더 많은 누수"가 발생할 수 있다는 의미가 아니라는 점 역시 알아두어야 한다. (이 글을 쓰고있는 현재에도 유효한) "예전의" ARC 작동 방식 역시 순환 참조 다루기와 같은 고유한 문제가 있었다. 내 생각에는 메모리 감지가 보다 어려웠다. 소개가 너무 길었다. 이 글의 소박한 목적은 델파이 애플리케이션에서 메모리 누수를 감지하는 데 사용할 수 있는 모든 도구의 최종적인 최신 리스트를 정리하는 것이다. 이제 메모리 관리가 통합 됨에 따라, 여기에 소개되는 도구들의 효과는 예전보다 훨씬 더 커졌다. 윈도우에서 메모리 누수를 감지하고 수정하는 작업은, 윈도우 뿐만 아니라 다른 플랫폼에서도 메모리 누수를 막을 수 있기 때문이다. 이제 리스트를 살펴 보자! 목차 FastMM (무료) LeakCheck (무료) Deleaker (상업용) EurekaLog (상업용) madExcept (상업용) AQTime Pro (상업용) Nexus Quality Suite (상업용) DDDebug (상업용) Spider (무료) 델파이 전용이 아닌 메모리 누수 감지 도구들 결론 FastMM (무료) FastMM (보다 정확히는 FastMM4)은 델파이에서 메모리 누수를 감지하는 사실 상의 표준 도구이다. 이유는 간단하다. 델파이의 기본 메모리 관리자로 이미 들어있고 바로 사용할 수 있기 때문이다. FastMM은 애플리케이션에 메모리를 할당 및 할당 해제한다. 따라서 할당 해제되지 않은 블록을 누구보다도 잘 보고한다. 프로젝트에 코드 한 줄만 추가하면, FastMM이 작동하기 시작한다. ReportMemoryLeaksOnShutdown := True; 예를 들면, program MyProgram; uses ... {$R *.res} begin Application.Initialize; ... {$IFDEF DEBUG} ReportMemoryLeaksOnShutdown := True; {$ENDIF} Application.Run; end. 짜잔 , 이제 이 애플리케이션은 종료될 때 모든 메모리 누수를 보고한다. 즉, 종료 시점에 감지된 모든 메모리 누수가 대화상자에 표시된다. 델파이 개발자라면 누구나 애플리케이션에 이 코드 한줄을 넣어야 한다. 반드시. 나는 델파이에 왜 이 코드가 기본으로 들어가지 않았는지 이해하지 못하겠다. 적어도 {$IFDEF DEBUG} 지시문으로 둘러싸서 넣을 수 있었을 텐데 말이다. 아마도 역사적인 이유가 있지 않을까 싶다. 델파이 안에 기본으로 메모리 누수를 감지하는 좋은 도구가 내장되어 있고, 잘 작동하니까 이제 이 글을 마쳐도 될 것 같겠지만, 몇 가지 더 알아두어야 할 것들이 있다. 델파이에 포함된 FastMM은 FastMM4에서 껍질을 벗겨낸 버전이다. 전체 버전이 아니므로, 당신에게 필요한 디버깅 기능이 없을 수도 있다. (예를 들어 누수된 메모리를 할당한 코드의 위치를 알려주지 않는다.) 코드의 위치까지 알고 싶으면 GitHub의 FASTMM4 공개 리포지토리에 있는 전체 버전을 사용해야 한다. 또한, DLL 하나를 사용해야 모든 디버깅 기능을 쓸 수 있다. 크로스 플랫폼 도구가 아니다. 공식적으로 윈도우에서만 작동한다 (공식 리포지토리에 맥OS 버전도 있는 것 같은데 내가 사용해 본 적은 없다). 많은 기능이 있긴 하지만 실제로 사용하려면 .INC 파일을 직접 다루고 구성해야 하므로 편하게 사용하기 어려운 사용자도 있을 것이다. 그러나, FastMM은 전반적으로 훌륭한 도구이며, 메모리 누수를 감지하는 델파이의 "표준" 도구이다. (참고: FASTMM5가 방금 출시되었다. 아직 테스트하지는 못했지만 다중 스레드 애플리케이션을 위한 성능 면에서 크게 향상된 것처럼 보인다. 어서 빨리 TMS XData에서 테스트해보고 싶다.) 장점 무료 전체 소스 코드가 있음 델파이 안에 들어있음 작동시키기 쉬움 고급 기능이 많음 단점 윈도우 전용 디버깅 기능을 쓰려면 외부 DLL이 필요함 고급 기능을 설정하고 사용하는 과정이 사용자에게 친근하지 않음(내장 GUI가 없음) FastMM 자체에서 할당한 메모리 누수만 보고됨 LeakCheck (무료) 델파이 LeakCheck 는 메모리 누수 감지를 위한 훌륭한 선택이 될 수 있다. 무료이며 오픈 소스이며 FastMM에 비해 다음과 같은 몇 가지 장점이 있다. 크로스 플랫폼이므로 모바일 및 Linux 애플리케이션에서 누수를 직접 확인할 수 있다. 그리고 유닛 테스트 프레임워크 (즉, DUnit 및 DUnitX ) 와 매우 잘 통합 된다. 시작하는 방법은 FastMM과 유사하다. dpr 소스 파일에 있는 uses 절의 가장 앞에 LeakCheck 유닛을 추가하면 LeakCheck가 플러그인되어서 사용할 수 있게 된다. 유닛 테스트를 위한 설정은 조금 더 복잡하지만 어차피 필요한 작업이다. 작은 단점을 하나 들자면, 대체로 사용자 스스로 알아서 사용해야 한다는 점이다. 이 프로젝트는 한동안 업데이트 되지 않고 있다. (잘 작동하기 때문에 나쁘게만 생각할 건 아니지만다). 사용자가 LeakCheck 작성자로부터 직접적인 도움을 받기는 힘들다는 의미이다 (내가 도움을 요청해 본 적은 실제로 없다). 게다가, 인터넷에 정보가 많지 않다. 공식 Bitbucket 저장소에 있는 상세 설명 외에 내가 인터넷에서는 찾은 정보는 사용법을 설명한 글 하나가 유일했다. 장점 무료 전체 소스 코드가 있음 크로스 플랫폼 유닛 테스트(DUnit 및 DUnitX)와 잘 통합됨 단점 사용법에 대한 정보가 많지 않음 최근 업데이트가 없고, 공식 지원이 없음 Deleaker (상업용) Delaker는 이 글에서 소개하는 메모리 누수 감지 전용 도구 중 유일한 유료 도구이다. 제품을 보면 이해할 만 하다. 메모리 누수 감지를 위한 정말 좋은 기능들이 제공된다. (역자주: [UX Summit 2021] Deleaker를 활용하여 메모리 누수 탐지하기 비디오 (11 min, 한국어 더빙)과, [도움말 번역] 딜리커 ( Deleaker)를 사용하여 "델파이" 에서 메모리 누수를 찾는 방법에서 Deleaker가 어떻게 작동되는 지를 쉽게 파악할 수 있다) 앞에 소개한 두 도구와 달리, 친숙한 GUI를 통해 환경을 설정하고 결과를 볼 수 있다. 독립적으로 실행할 수도 있고, 델파이 IDE에 통합시킬 수도 있다. 또한 GDI 누수, 윈도우의 사용자(USER) 오브젝트와 핸들의 누수, 윈도우 API 누수, 써드파티 DLL의 누수 등 훨씬 더 많은 유형의 메모리 누수를 감지할 수 있다. 그런 이유 때문에, Deleaker가 무시할 메모리 누수 유형 지정이 쉽다. – 이런 제외 설정을 하지 않으면, 일반 앱 하나만 실행해도 엄청나게 많은 누수 정보를 얻게 된다. 메모리 할당 스냅샷을 찍는 기능 역시 매우 유용하다. 이를 통해 애플리케이션이 동작하는 전체 시간 뿐만 아니라 애플리케이션의 일부 특정 작업 안에서 발생되는 누출을 감지할 수 있다. 장점 독립 실행형으로 사용하거나 델파이 IDE에 통합할 수 있는 친숙한 GUI 모든 유형의 누출을 감지 CI (지속적 통합)과 연동 가능 (명령줄 도구 제공) 메모리 사용 스냅샷 공식 지원이 제공됨 단점 유료 라이선스(홈 라이선스의 경우 $99, 단일 개발자 라이선스의 경우 $399) 윈도우 전용 EurekaLog (상업용) EurekaLog는 베테랑이다. 지난 수십 년 동안 존재해 왔다. 첫 버전 출시가 언제인지 공식 웹사이트에 나와있지 않지만, 나는 18년 전인 2002년에 EurekaLog 4.0이 출시되었다는 기록을 찾을 수 있었다. EurekaLog는 메모리 누수 감지만 하는 도구가 아니다. 누수 감지는 전체 기능 중 일부일 뿐이다. EurekaLog의 목적은 애플리케이션 사용하는 고객이 경험하는 모든 문제( 예외, 누출 등 )를 감지하여 개발자에게 다시 보고하는 것이다. 따라서, 소프트웨어 품질을 개선하고 고객 지원을 향상하는 데 도움이 되는 훌륭한 도구이다. 다른 환경에서 다양한 작업을 수행하는 모든 고객으로부터 오류 및 누출 보고를 받을 수 있기 때문이다. 또한, ("개발자 환경에서는 재현이 안되는" 상황 등) 고객의 환경에서만 발생하는 까다로운 버그를 찾는 데 에도 역시 도움이 된다. 장점 메모리 및 리소스 누수를 모두 감지 고객 측에서 감지된 누출 및 오류를 개발자에게 자동 전송 가능 기타 다양한 기능: 버그 보고, 버그 추적 시스템과의 통합 등 공식 지원이 제공됨 단점 유료 라이선스(Professional 라이선스의 경우 $149, Enterprise 라이선스의 경우 $249) 윈도우 전용 메모리 누수 감지를 위한 고급 기능이 많지 않음 madExcept (상업용) 나는 MadExcept가 EurekaLog의 "사촌"이라고들 말한다. 둘 다 (약 20년 이상) 거의 동시대의 도구이다. 비슷한 기능도 많고 목적도 거의 같다. 웃기게도 "승자"는 없다. 이 둘을 비교하려고 인터넷을 둘러본다면 어떤 것이 "더 낫다"는 결론을 낼 수 없을 것이다. 두 제품 모두 고객들이 대체로 자신들이 사용하는 제품에 만족해서 경쟁 제품을 사용해 본 적이 없기 때문에 비교 의견을 내지 못하는 것 같다. 사실 내 경우가 그렇다. 나는 madExcept를 사용한 적이 없다. (메모리 누수를 잡기 위해서가 아니라 다른 목적으로 사용했지만) EurekaLog에 매우 만족한다. 만약 내가 EurekaLog 대신 madExcept를 사용하더라도 잘 사용하고 만족했을 것이다. 따라서, 나는 madExcept와 EurekaLog는 장단점도 같다고 본다. 유일하게 눈에 띄는 차이점이라면 (비상업적 용도를 위한 무료 버전도 있는) madExcept는 더 저렴하고, EurekaLog는 훨씬 더 활발하고 자주 업데이트되는 것 정도이다. 장점 비상업적 용도는 무료 메모리 및 리소스 누수를 모두 감지 고객 측에서 감지된 누출 및 오류를 개발자에게 자동 전송 가능 기타 다양한 기능: 버그 보고, 버그 추적 시스템과의 통합 등 공식 지원이 제공됨 단점 유료 라이선스(전체 소스 라이선스의 경우 € 159) 윈도우 전용 메모리 누수 감지를 위한 고급 기능이 많지 않음 AQTime Pro (상업용) AQTime은 코드 개선 목적으로는 어느 무엇보다도 최고의 도구이다. 고급 메모리 누수 감지 (훌륭한 GUI, 스냅샷, 메모리 추적, 리소스 누수 고급 감지 등) 뿐만 아니라 성능 프로파일링 (인스트루먼트 및 샘플링 프로파일러 모두 사용), 코드 커버리지, 코드 분석을 제공하는 정말 수준 높은 도구이다. 정말 멋진 도구이지만 단점이 있다. 꽤 비싸고 "유지 보수" 위주로 운영하는 것으로 보인다. 일년에 한 번 정도 업데이트 되고, "새로운 델파이 버전 지원"이 대부분이다. 지난 몇년간 몇가지 버그 수정이 있었으며 새로운 기능은 거의 없었다 . 하지만 글쎄, 많고 강력한 기능 면에 델파이 세계에서 AQTime에 견줄 만한 도구는 없다. 장점 메모리, 리소스, GDI, 핸들 누수를 감지 실시간 할당 모니터 스냅샷 번들 안에 다른 많은 도구가 포함됨(성능 프로파일러, 코드 커퍼리지 등) 단점 상당히 높은 가격(노드 고정 라이선스의 경우 $719, 플로우팅 라이선스의 경우 $2279) 윈도우 전용 Nexus Quality Suite (상업용) Nexus Quality Suite는 방식이 EurekaLog나 madExcept와 유사하면서도, 어느 정도는 AQTime과 관련이 있다고 생각한다. AQTime과 Nexus Quality Suite는 둘 다 소프트웨어 품질을 향상시키기 위한 많은 도구를 제공하며 이들 사이에는 겹치는 부분이 있다. Nexus Quality Suite는 메모리 및 리소스 누수 감지기 뿐만 아니라 성능 프로파일러, 라인 타이머, 코드 검사, GUI 자동 테스터 등을 제공하다. 나는 메모리 검사 도구를 직접 써 보지는 않았으므로 장단점은 웹 사이트에서 읽은 내용을 기반으로 정리했다. 장점 메모리 및 리소스 누수를 모두 감지 공식 지원이 제공됨, 지원 포럼이 활동적임 패키지에 다른 많은 도구가 포함됨 단점 유료 라이선스(AUD 490, 약 $300) 윈도우 전용 DDDebug (상업용) 제조사의 웹사이트에서 의하면, DDDebug는 메모리 프로파일러, 스레드 뷰어, 모듈 뷰어 및 향상된 예외 처리기 등 여러 모듈이 포함된 디버깅 도구 모음이다. DDDebug는 약간 다른 접근 방식을 가지고 있다는 점이 나는 흥미로웠다. 메모리 사용량과 통계를 애플리케이션 내부에서 즉시 제공하기 때문에, 내가 사용해보지는 않았지만, 분석과 동시에 앱과 상호 작용할 수 있어서 앱에 있는 버그를 더 쉽게 찾을 수 있는 것 같다. DDDebug는 플러스인 패키지에도 작동한다. 메모리 누수 감지 외에도 더 많은 기능을 제공하며 상용이지만 라이선스 가격이 부담스럽지 않다. 장점 GUI를 통해 애플리케이션 내부에 결과를 직접 제공 패키지를 지원함 공식 지원이 제공됨 부담스럽지 않은 라이선스 가격(€59부터) 단점 윈도우 전용 Spider (무료) 스파이더 웹사이트에는 예외 분석, 실시간 메모리 사용 분석, 메모리 누수 분석, 호출 스택 분석 등 흥미로운 기능이 많이 나열되어 있다. 난 한번 밖에 시도해보지 않았는데 사용자 화면과 결과 자체가 혼란스러워서 사용할 수 없었다. 하지만, 나만 그럴 수도 있는 문제라서 여기 리스트에 올려두기로 했다. 하지만, 나는 Spider에 대해서 공평한 평가를 할 수 없다. 장점 무료 소스 코드가 있음 단점 혼란스러운 사용자 인터페이스(개인 의견) 델파이 전용이 아닌 메모리 누수 감지 도구들 델파이 전용 또는 델파이 IDE나 소스 코드에 연결되는 도구들 외에, 메모리 누수 감지용 범용 도구들이 있다. Valgrind (무료) Valgrind는 인스트루먼트 프레임워크이다. 이 프레임워크 안에는 많은 도구들이 있으며 자신의 도구를 추가할 수도 있다. 포함된 도구 중 하나인 memcheck는 애플리케이션 누수를 감지할 때 도움이 된다. 나는 Linux 애플리케이션에서 발생하는 메모리 누수를 감지 할 때 Valgrind를 많이 사용하는데, 실제로 사용법이 매우 간단하다. Valgrind를 실행하면서 명령줄 매개변수에 검사하려는 애플리케이션 경로를 적어주기만 하면 된다. 그러면 Valgrind가 애플리케이션을 구동시키고, 애플리케이션이 끝나면 발생될 수 있는 누수 등 자세한 정보가 담긴 보고서를 제공한다. 물론 로그를 파일에 기록, 호출 스택 크기 지정, 탐지 수준 선택 등 많은 명령줄 옵션을 사용할 수도 있다. Instrument (무료) Apple Instruments는 강력하고 유연한 성능 분석 및 테스트 도구이며 Xcode 도구 세트의 일부이다. 무엇보다도 iOS 및 맥OS 애플리케이션에서 발생하는 누출을 감지할 때 사용한다. Adrian Gallero가 iOS 애플리케이션의 누출을 감지 하기 위해 Instruments 를 사용하는 방법에 대한 훌륭한 글을 TMS Software 블로그에 게시했다. 조금 오래된 글이지만 여전히 유효하다고 믿는다. 결론 승자가 없다 . 각 도구마다 고유한 장단점이 있으며 상호 배타적이지 않다는 점에 유의하자. 실제로 나 역시 목적에 따라 이 도구들 중 몇 가지를 직접 사용한다. 나는 FASTMM을 사용하여 "매일" 메모리 누수를 탐지한다. LeakCheck는 유닛 테스트에서 사용한다. Deleaker는 다른 유형의 누수를 확인하거나, 스냅샷이 필요할 때 사용한다. EurekaLog는 내 최종 사용자 애플리케이션이 버그 리포트를 하도록 만들 때 사용한다. AQTime은 대한 성능 프로파일링을 할 때, Valgrind는 Linux에서 누수를 감지할 때 사용한다. 보다시피 모두 유용하다! 무엇보다 애플리케이션에서 메모리가 새어나가지 않도록 하자! 이런 주제가 처음이라면, 지금 바로 해야할 것을 알게 되었을 것이다. ReportMemoryLeaksOnShutdown := True; 위의 코드 한 줄을 애플리케이션에 추가하고 누수 잡기를 시작하자! (리스트에 포함되어야 하는 다른 도구를 알고 있거나, 나열된 도구에 대해 다른 의견이 있다면, 아래에 댓글을 달아서 지식을 공유해 주기 바란다. 이 글이 완전한 리스트이 되는데 크게 도움이 될 것이다. 나 역시 새로운 내용이 알게 되면 자주 업데이트하겠다.)
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.