아자!

jemalloc 라이브러리가 정상 작동하므로 솔루션에 포함되어 있는 test_threads 프로젝트를 빌드해본다.

별 설정 없이도 잘 빌드되고 실행된다.

….만, 이게 도대체 뭔 내용인지는 나도 잘 모르겠다. test_threads.cpp 파일에는 테스트용 코드가 잔뜩 있다. 다 읽어보기도 힘들어서 읽어보다가 관둿다. 대략 je_malloc, je_free 등의 함수를 이용하는 예제코드인 것 같다.

github에는 간단한 예제코드가 있다. ( https://github.com/jemalloc/jemalloc/wiki/Getting-Started )

….는 별로 도움이 되지 않았다.

그냥 쉽게 얘기하면 new/malloc 을 할 때 je_malloc 을 하면 되고 delete/free 를 할 때 je_free 를 하라면 되는 말.

그래서 new와 delete를 오버라이딩하는 클래스를 만든다.

	#pragma once
	class MemoryPool
	{
	public:
	MemoryPool(void) {}
	virtual ~MemoryPool(void) {}
	void* operator new(size_t size)
	{
	return je_malloc(size);
	}
	void* operator new[](size_t size)
	{
	return je_malloc(size);
	}
	void operator delete(void* ptr)
	{
	je_free(ptr);
	}
	void operator delete[](void* ptr)
	{
	je_free(ptr);
	}
	private:
	};

view rawMemoryPool.cpp hosted with  by GitHub

new 를 사용하는 곳에서 이 오버라이딩 클래스를 상속 받게 해주면 끝.

그리고 헤더에서 #include <jemalloc/jemalloc.h> 를 넣어주고 추가 포함 디렉터리에는 jemalloc의 include 디렉토리를 지정해주고 빌드하면 된다.

이렇게하면 빌드가 성공하고 실행파일에 있는 위치에 jemalloc 빌드 후 생성된 .dll 파일을 같이 넣어주면 된다.

….인줄 알았는데 빌드가 안된다.

코드를 보니 jemalloc.h 파일에서

#include <string.h> 부분이 문제가 되었다. 이 문제에 대해 찾아보니…

https://stackoverflow.com/questions/15512790/error-about-finding-strings-h-in-htmlcxx

아마 유닉스쪽에서 쓰는 헤더파일일 거라고 한다.

해당 부분을

로 교체하면 잘 작동한다.

프로젝트의 구성속성을 보면 Debug, Debug-static 식으로 나뉘어 있는데, 전자는 .dll 파일을 쓰는 동적 링크, 후자는 .lib 파일을 쓰는 정적 링크이다. 각자 원하는 것으로 사용.

원글 : https://blog.dongbumkim.com/archives/5088

일단 https://github.com/jemalloc/jemalloc 에서 소스코드를 Clone 한다. (내 경우에는 D:\Library\jemalloc 으로 다운로드했다.)

master 브랜치를 다운로드하고 안에 들어가서 살펴보면 msvc 라는 디렉토리가 있고 그 안에 jemalloc_vc2015.sln 파일이 있다. Visual Studio 2015용 솔루션이 있으니 얼마나 감사한가.

솔루션을 열어보면 이미 jemalloc 프로젝트와 test_threads 프로젝트가 추가되어있다.

jemalloc 프로젝트를 빌드해보면…

C1083 포함 파일을 열 수 없습니다. 'jemalloc/internal/jemalloc_preamble.h': No such file or directory jemalloc d:\library\jemalloc\src\witness.c 2

오류와 함께 빌드가 되지 않는다. 실제로 저 경로에 가서 살펴보면 jemalloc_preamble.h 파일이 없다.

솔루션 파일에 추가되어 있는 ReadMe.txt 파일을 열어보면 다음과 같은 내용이 있다.

How to build jemalloc for Windows
=================================

1. Install Cygwin with at least the following packages:
* autoconf
* autogen
* gawk
* grep
* sed

2. Install Visual Studio 2015 with Visual C++

3. Add Cygwin\bin to the PATH environment variable

4. Open "VS2015 x86 Native Tools Command Prompt"
(note: x86/x64 doesn't matter at this point)

5. Generate header files:
sh -c "CC=cl ./autogen.sh"

6. Now the project can be opened and built in Visual Studio:
msvc\jemalloc_vc2015.sln

메뉴얼이 있으니 따라가야지.

Cygwin을 구글에서 검색해서 설치한다. Cygwin 설치법은 검색해서 찾자.

하나 참고해둘 것은 Cygwin은 설치프로그램을 실행해서 구성파일을 인터넷에서 다운로드하며 설치한다. 근데 이 과정이 무지막지하게 느리다. 기가인터넷이고 지랄이고 이런거 소용 없더라. 미러를 선택할 때 ftp.kaist.ac.kr을 선택했지만 그래도 느리다. 한참 설치하더니 몇가지 패키지가 설치 안되었다고 나온다. 설치프로그램을 다시 실행시켜서 미러를 ftp.jaist.ac.jp 로 바꾸고 다시 설치. 이 과정을 몇번 반복해서야 겨우 설치 완료했다.

Cygwin을 디폴트로 설치하고나서 설치프로그램의 검색창을 이용해 위 메뉴얼에 있는 autoconf, autogen, gawk, grep, sed를 설치해줘야 한다. 잊지말것.

아마 Cygwin을 처음 보거나 잘 쓰지 않는 사람이라면 이 과정에서 굉장히 스트레스 받을 것이다. 나도 Cygwin 설치에만 하루 넘게 걸렸다. 젠장…

이걸 설치하고 나서는 메뉴얼대로 제어판을 열고 ‘시스템’의 ‘고급 시스템 설정’의 ‘환경 변수’에 가서 ‘변수’ 중 Path 항목의 값에 Cygwin의 bin 경로를 추가해준다. 내 경우에는 C:\cygwin64\bin 을 추가해줬다.

이제 시작메뉴에서 ‘VS2015 x64 네이티브 도구 명령 프롬프트’를 실행한다.

경로를 jemalloc이 설치된 폴더로 이동한다. 내 경우에는 D:\Library\jemalloc 으로.

메뉴얼에 있는대로 sh -c “CC=cl ./autogen.sh” 를 입력한다.

각종 환경설정 사항을 체크하고 컴파일 과정이 지나간다. (다중프로세서 컴파일은 하지 않는듯하다. 적당히 웹서핑하며 몇분 기다리면 된다.)

이 화면이 나오면 컴파일이 끝난 것이다.

아까 jemalloc_preamble.h 파일이 없던 경로에 가보면 jemalloc_preamble.h 파일이 생성되어 있다.

이제 다시 Visual Studio 2015를 켜서 솔루션을 열고 jemalloc 프로젝트를 빌드해본다.

당연히 잘된다. ㅎㅎㅎ

결론 : Cygwin을 설치하는게 제일 애먹었다. 이것만 설치하고 나머지는 메뉴얼대로 설정하면 된다.

한 사이트에서 개발한 프로그램이 가끔 이유없이 죽고 있었다.

다른 사이트는 그런 일이 없는데 그 사이트에서만 발생하고 있는 일이었다.

보통은 로그를 이용하여 원인을 파악하는데,

그 사이트는 로그가 너무 많이 쌓여서 로그 유지 기간이 짧았고,

반면 프로그램이 다운되는 일은 어쩌다 (한, 두 달에 한 번정도) 발생되는 일이라서 골치가 아팠는데

이 기회에 Breakpad를 적용해서 해결해 보려고 마음 먹었다.

1. Breakpad 소개

Google breakpad home page : https://code.google.com/p/google-breakpad/

Google Chrome처럼, 여러 플랫폼을 지원하는 프로그램을 위한 크래시 덤프를 다루기 위한 툴이다.

Win32 개발자들이 접하는 minidump나, *nix 개발자들이 접하는 coredump를 breakpad 포맷(이라기보단 함수 맵)으로 변경하고, 이를 이용해서 플랫폼이 바뀌어도 같은 형태의 스택 트레이스(stack trace)를 볼 수 있게 해주는 툴이다.

좀 더 세부적으로 보면 다음과 같은 부분으로 되어 있다.

(개별 사용자 용) 크래시가 발생했을 때, 이를 breakpad 에서 사용하는 포맷으로 덤프를 남겨주는 부분: in-process 덤프만 있는 게 아니라, 다른 프로세스에서 dump를 남기는 방식(out-of-process dump)도 지원한다
(Build-System 용) 디버그 정보를 읽어서 breakpad 내부 형식으로 바꾸는 부분 : Win32 pdb 나 –g 옵션을 넣고 빌드한 *nix 바이너리에서 심볼 데이터를 뽑아낸다
(Crash Collector 용) 1에서 나온 정보를 가지고 2를 이용하여 스택 트레이스를 뽑아내는 부분

사실 2, 3 부분은 Windows 환경에서만 프로그래밍 한다면 그다지 중요하지 않다. 어차피 breakpad 도 덤프 자체는 minidump를 쓰고 있고, breakpad 소개의 Build / User / CrashCollector system 다이어그램에 나온 과정도, 디버그 정보가 애초에 분리되어 빌드 되는 환경(/Z7 같은 걸 쓰면 모르겠지만)에선 그다지 더 편해질 건 없다.

그렇지만 1에서 Windows named-pipe를 써서, 크래시가 발생한 프로세스가 아니라, 안전하게 동작 중인 프로세스에서 덤프를 남길 수 있다는 점(Out-of-process 덤프), 그리고 이 덤프 남기는 부분의 코드에서 제공하는 callback 지점들이 적당해서, 이걸 이용해서 간단하게(!) 실제 배치된 시스템의 덤프를 중앙의 서버로 모으는 작업을 간편하게 작성할 수 있었다.

일단 out-of-process로 덤프를 남길 수 있기에, 크래시가 발생한 바이너리에서 할 수 없는 일들 – 메모리 신규 할당, heap 메모리 참조, 기타 등등 – 을 맘대로 해도 되기 때문에 웹 서버나 다른 서버로 덤프를 보내는 일이 쉬워진다.

– rein’s world

out-of-process

breakpad 의 가장 큰 특징은 out-of-process 를 지원하는 것이다. 크래시를 처리하는 함수에서 앞에서 말한 다양한 기능을 추가한다면 제대로 동작하지 않을 수도 있다. 간단한 예로, 사용자에게 의견을 받는 윈도우를 띄운다고 할 때 메인 스레드의 메시지 루프가 깨지면 윈도우 자체를 볼 수 없게 된다.

크래시가 발생한 프로세스 밖(out-of-process)에서 처리하면 이와 같은 문제를 줄일 수 있다. 그래서 크래시 발생을 처리하기 위해 보다 많은 것을 제공할 수 있다. 물론 in-process 도 지원하기 때문에 필요에 맞게 골라 쓰면 된다.

크로스 플랫폼

멀티플랫폼 지원을 고려한다면 breakpad 는 좋은 선택이 될 수 있다. breakpad 를 사용한다면 크로스 플랫폼에 대한 고민을 줄여줄 수 있다.

– 야드버즈의 개발 로그

breakpad를 현재 사용하고 있는 대표적인 프로그램은 Chrome Browser, Firefox Browser, Picasa, Google Earth 등이다.

2. Breakpad 받기

Breakpad는 SVN을 이용하여 내려 받을 수 있다.

SVN은 서버까지 필요 없으므로 Windows용 tortoiseSVN을 설치하면 된다.

tortoiseSVN을 설치했으면 다음과 같이 내려 받는다.

1) Command 창을 열어 먼저 설치하고 싶은 폴더로 이동한뒤, 다음과 같이 실행한다.

svn checkout http://google-breakpad.googlecode.com/svn/trunk/ google-breakpad-read-only

그러면 google-breakpad-read-only 폴더가 생기면서 그 폴더로 checkout을 하고, 소스를 내려 받는다.

2) 탐색기에서 설치하고 싶은 폴더를 만든 뒤, 마우스 오른쪽 버튼을 눌러 로 ‘SVN Checkout’을 선택한다.

URL of Repository 항목에 ‘http://google-breakpad.googlecode.com/svn/trunk’ 를 넣고  OK를 누른다.

그러면 그 폴더로 checkout을 하고, 소스를 내려 받는다.

3. Breakpad build 하기

1. 1. python 2.x버전 설치: breakpad는 gyp를 이용하여 빌드 시스템을 생성한다. gyp를 사용하기 위해서는 python 2.x버전이 필요하다. gyp가 아직 python 3.x버전과는 호환성 문제가 있는 것 같다. (gyp 자체 문제 + gyp 설정 파일문제가 복합적인듯 하다.)
2. gyp 소스 가져오기: breakpad 소스 내에 gyp가 내장되어 있지만, 내장 gyp는 버전관리가 안되어 있는듯 하다. gyp 최신 버전이 적용이 안되어 있다. 현재 작성 시간 기준 gyp 최신 소스에는 Visual studio 2012까지 빌드 시스템을 생성할 수 있도록 되어있다. gyp 최신버전을 사용하기 위해서 gyp를 google 저장소에서 checkout하면 된다.
3. gyp로 빌드 시스템 생성: src\client\windows 폴더에서 ..\..\tools\gyp\gyp.batbreakpad_client.gyp 를 실행하면 솔루션 파일과 프로젝트 파일이 생성되는 것을 볼 수 있다.
4. Visual Studio로 빌드: 만들어진 솔루션 파일을 열어 그 안에 있는 build_all 프로젝트를 빌드하면 된다.

4. Breakpad test

테스트용 프로그램(crash_generation_app 프로젝트)이 솔루션에 포함돼 있으므로 따로 만들 필요는 없다. 이 테스트 프로그램을 이용하면 in-process 뿐만 아니라 out-of-process 미니덤프도 만들어 볼 수 있다. 여기에서는 out-of-process 미니덤프를 만드는 방법을 소개하겠다.

프로그램을 실행하기에 앞서 C:\Dumps 폴더를 만들어야 한다. 이 폴더를 만들지 않으면 미니덤프를 저장하다가 실패한다.

준비가 다 됐다면 프로그램을 실행해 보자. 제대로 된 out-of-process 를 테스트하기 위해서는 프로세스를 두 개 띄워야 한다. 두 번째 프로세스를 띄울 때 서버를 실행할 수 없다는 에러 메시지가 뜨지만 무시해도 좋다. 그런 다음 서버가 실행되지 않는 프로세스에서 Client -> Deref Zero 메뉴를 선택해 강제로 크래시를 발생시키면 C:\Dumps 폴더에 미니덤프 파일이 생성되는 것을 볼 수 있다.

– 야드버즈의 개발 로그

참고자료

Breakpad 로 CrashReporter 만들기 – rein’s world

원도우즈 환경에서 breakpad 사용하기 – 야드버즈의 개발 로그

[추가]

../gyp/gyp.bat breakpad_client.gyp --no-circular-check

위 옵션을 꼭 넣어야 솔루션파일이 만들어진다.

출처

https://arodream.wordpress.com/2015/04/17/google-breakpad%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-creash-dump-%EB%96%A8%EC%96%B4%EB%9C%A8%EB%A6%AC%EA%B8%B0/

장시간 프로그램 실행시 메모리가 증가하는 경우, 자원 해제를 빼먹은 부분을 찾아주는 유용한 툴 중 하나인,

"Visual Leak Detector for Visual C++ 2008/2010/2012/2013"라는 유용한 라이브러리를 소개합니다.

설치 후 간단하게 프로젝트에 헤더파일 추가와 경로설정만하면 끝!

1. 다운로드 & 설치

2. C++ 프로젝트에 VLD 경로 추가

Visual C++ 프로젝트 속성을 클릭하여 VC++ 디렉터리의 포함/라이브러리 디렉터리에 VLD의 경로를 추가합니다.

1) 포함 디렉터리 추가

ex) "C:\Program Files (x86)\Visual Leak Detector\include"

2) 라이브러리 디렉터리 추가

ex) "C:\Program Files (x86)\Visual Leak Detector\lib\Win32" (개발하는 프로그램이 32bit인 경우)

3. VLD 헤더파일 추가

VLD를 사용하기 위한 헤더파일을 소스에 추가합니다.

4. 메모리 누수 체크하기

간단한 샘플 코드를 실행하여 종료시킨 후의 DEBUG 로그를 확인합니다.

디버그로그에 보면 파일의 경로와 함께 "memoryleaktest.cpp (6)"이라고 출력이되었고, 

해당 파일의 6번째 라인을 보면 누수된 코드를 확인 할 수 있습니다.

* 메모리 누수가 체크된 경우

* 메모리 누수가 없다고 체크된 경우

메모리 누수가 없는 경우는 아래와 같이 출력됩니다.

* 샘플 코드

◆ VLD 출력 설정하기

출력 데이터를 파일로, callstack level 설정 등을 변경하고 싶다면 vld.ini 파일을 수정합니다.

(설치된 경로에 위치)

* 출력 데이터 경로 설정하기 : 파일 및 debugger

1) ReportTo 값을 Both로 변경하여 debugger와 파일로 동시 출력하게 설정

2) 파일 확인

출처: http://dg087.tistory.com/9 []

구조체는 메모리에 어떤 식으로 저장될까
다음과 같은 소스를 보자.

 

1. #include <stdio.h>   
2.   
3. typedef struct _TEST{   
4.     char cData;   
5.     short sData;   
6.     int iData;   
7. }TEST;   
8.   
9. int main()   
10. {   
11.     TEST TData={0,};   
12.   
13.     printf("cData size : %d\n", sizeof(TData.cData));   
14.     printf("sData size : %d\n", sizeof(TData.sData));   
15.     printf("iData size : %d\n", sizeof(TData.iData));   
16.     printf("TData size : %d\n", sizeof(TData));   
17.        
18.     return 0;   
19. }  

TEST 구조체 변수인 TData는 char형 데이터(1byte), short형 데이터(2byte), int형 데이터(4byte)를 가지고 있으므로 1+2+4=7byte의 크기를 가질 것 처럼 보인다. 하지만 이 소스를 컴파일하고 실행을 해보면 다음과 같은 결과가  나온다.

 

분명히 cData(1) + sData(2) + iData(4) = 7임에도 불고하고 TData의 크기는 8바이트라고 하니 참 이상한 일이다.

이는 현재 우리가 쓰는 32비트 컴퓨터에서 32비트 컴파일러를 사용하였기 때문에 32비트 즉, 4바이트로 데이터를 처리하는 것에 가장 최적화되어 있기 때문에 데이터를 4바이트 공간으로 저장하기 때문이다.

이 TData란 구조체는 8바이트에 다음과 같이 저장되어 있다.

cData

??

sData

sData

iData

iData

iData

iData

cData를 저장하고, 4바이트중에 3바이트가 남아있기 때문에 sData를 3바이트 중에 2바이트의 공간에 저장하고,
iData를 저장하려 하니 1바이트밖에 남아있지 않기 때문에 4바이트의 공간을 따로 만들어 저장하게 되는 것이다.

그럼 이제 위의 소스에서 변수 선언의 순서를 한 번 바꿔 보자.

 

1. typedef struct _TEST{   
2.     char cData;   
3.     int iData;   
4.     short sData;   
5. }TEST;  

 
변수 선언의 순서를 바꿨을 뿐인데 신기하게도 같은 구조체의 크기가 8에서 12로 늘어나버렸다.
이 TData 구조체 변수는 다음과 같이 저장되어 있을 것이다.

cData (1byte)

empty (3byte)

sData (2byte)

empty (2byte)

iData (4byte)

이처럼 컴파일러는 4바이트에 맞춰서 데이터를 저장하는 것을 볼 수 있다. 이것을 막으려면 어떻게 해야할까.

이것을 해결하려면 #pragma pack() 이라는 전처리어를 사용하면 된다.
구조체 하나를 더 추가한 다음 소스를 보자.

 

1. #include <stdio.h>   
2.   
3. typedef struct _TEST{   
4.     char cData;   
5.     int iData;   
6.     short sData;   
7. }TEST;   
8.   
9. #pragma pack(1)   
10. typedef struct _TEST2{   
11.     char cData;   
12.     int iData;   
13.     short sData;   
14. }TEST2;   
15.   
16. int main()   
17. {   
18.     TEST TData={0,};   
19.     TEST2 TData2={0,};   
20.   
21.     printf("TData size : %d\n", sizeof(TData));   
22.     printf("TData2 size : %d\n", sizeof(TData2));   
23.        
24.     return 0;   
25. }  

 
#pragma pack(1)에서 1은 1바이트 단위로 저장하겠다는 것이다. 따라서 TData와 TData2의 내용물은 같으나 크기는 다른 것을 확인할 수 있다.

 그렇다면, 왜 모두 1바이트로 해서 메모리의 낭비가 없도록 하지 않는 것일까?
 그것은, 아까도 이야기하였듯이 32비트 CPU에서는 4바이트(32비트)의 단위로 데이터를 처리하는 것이 가장 빠르게 때문이다. 즉, #pragma pack(1) 이라고 선언해놓고 원래대로 돌려놓지 않는다면 속도저하의 문제가 생길 수 있다.
 따라서, 위의 소스에서 구조체 선언이 끝나는 부분에 #pragma pack(4)라고 선언해주어 할 것이다.

 하지만, 여기에도 문제가 있다.
 만약, 이 소스를 32비트의 PC가 아닌 다른 CPU가 장착된 장비에서 컴파일하게 된다면 어떻게 될 것인가. 예를 들면 임베디드 시스템 같은 8~16비트 CPU에서 말이다.
 소스를 일일히 찾아서 CPU에 맞게 고쳐주고 다시 컴파일해야 되는 불편함과 어려움이 생기게 된다.

 이럴때를 위해서 좀 더 우아하게 쓰는 코드가 있다.

 

1. #pragma pack(push, 1)   
2. typedef struct _TEST2{   
3.     char cData;   
4.     int iData;   
5.     short sData;   
6. }TEST2;   
7. #pragma pack(pop)  

 기존의 바이트를 스택에 push하고 1바이트 단위로 처리한다음 끝나는 부분에 원래의 바이트 단위를 pop해주는 코드이다. 보통은 이렇게 사용하면 되겠다.


 
아래와 같은 코드를 사용하면 구조체 크기는 1바이트가된다.

1. #pragma pack(push, 1)   
2. typedef struct DATA{   
3.     char cData;      
4. }DATA;   
5. #pragma pack(pop)  

출처: http://javawoo.tistory.com/30 []