반응형


tcmalloc, jemalloc 그리고 nedmalloc


복사

http://blog.naver.com/sorkelf/40189432780


TCMalloc

 

TCMalloc은 (Thread - Caching Memory Allocation) 의 약자로 구글에서 만든 메모리 할당 라이브러리 이다.

 

중앙메모리 관리자와 스레드별 메모리 관리자를 구분하여 32K이하의 작은 크기인경우에 메모리 할당/해제 요청은 스레드별 메모리 관리자가, 부족할 경우 중앙 메모리 관리자에서 얻어오는 형태를 띄고 있다.

메모리 할당시 불필요한 동기화 과정이 거의 없으므로 보다 좋은 성능향상을 얻을 수 있다.

 

 

 

TCMalloc에 문서에서는 32k 이하의 작은 크기인 경우에 대한 메모리의 할당 해제가 ptmalloc2보다 약 6배 빠르다고 하고 있다.


사용법은 매우 간단하다.

 

아래 사이트에서 최신 버전에 구글 퍼포먼스툴을 다운받고

 

https://code.google.com/p/gperftools/downloads/detail?name=gperftools-2.0.zip

 

프로젝트 빌드를 한뒤 생성되는 라이브러리를 사용하려는 해당 프로젝트에 링크 시켜주면 끝이다.

 

아래는 사용법에 관한 원문

 

Usage

To use TCmalloc, just link tcmalloc into your application via the "-ltcmalloc" linker flag.

You can use tcmalloc in applications you didn't compile yourself, by using LD_PRELOAD:

   $ LD_PRELOAD="/usr/lib/libtcmalloc.so" <binary>
</binary>

LD_PRELOAD is tricky, and we don't necessarily recommend this mode of usage.

 

 

또한 구글 퍼포먼스 툴에서는 

Heap Checker, Heap Profiler, CPU Profiler의 TCMalloc 이외에도 메모리 누수 디버깅, 프로파일링에 좋은 툴들을 제공하고 있다.

레퍼런스도 많이 존재하며 임베디드 및 iOS도 지원해서 보편적으로 사용중에 있다.

 

 

NedMalloc

 

Ogre3D에 새로운 메모리 할당자로 채택 된 NedMalloc은 Hoard, ptmalloc2 보다 빠르다고 한다.

c++ 코드로 이루어져있으며 윈도우에 최적화 되어 있다.

파일도 3개만 추가하면 되므로 프로젝트에 적용하기 용이하다..

 

 

To Use:

Drop in nedmalloc.h, nedmalloc.c and malloc.c.h into your project.

Configure using the instructions in nedmalloc.h. Run and enjoy.

 

To test, compile test.c. It will run a comparison between your system

allocator and nedalloc and tell you how much faster nedalloc is. It also

serves as an example of usage.

 

 

http://www.nedprod.com/programs/portable/nedmalloc/

 

홈페이지에서 말하는건.. tcmalloc은 서버프로세스에서 사용하는것이 좋음

 

 

JEMalloc

 

JEMalloc은 (Jason Evans)가 만들어서 JEMalloc이라 부르며 현재 페이스 북, 파이어폭스에서 사용하고 있는 메모리 할당 라이브러리이다.

http://www.canonware.com/jemalloc/download.html

 

 

 

위에 나와있는 도표 중 jemalloc이 가장 좋은 성능을 보이고 있지만, tcmalloc과의 큰 차이를 보이고 있진 않다.

Jason Evans도 실코어 8개 이상 컴퓨터에서는 jemalloc이 더 좋은 성능을 보인다고 이야기 해보았을때 아직까지는 두 개의 성능이 크게 차이 나지는 않는 듯 하다..


스택 오버플로우에 한 답변에는 아래와 같은 이야기가 있다..

 

tcmalloc은 메모리 풀을 사용하는 등의 정적인 스레드일 경우 효과적이며

jemalloc은 스레드를 생성하거나 파기할때의 효과적이다.

 

두개 다 프로젝트에서 사용해보고 더 나은 것을 찾는게 제일 낫지 싶다.

 

 그 외 조사해볼 라이브러리 - LKMalloc, HOARD, PTMalloc3, OpenBSD 등등..


반응형
반응형
http://blog.naver.com/swoosungi/90024620229

freetyped3d-swoosungi.zip




자존심님 이야기를 듣고 FreeType에 관해 찾아보았습니다.

일단 참고 홈페이지는 http://www.freetype.org/ 여기더군요...

프리타입에 관해 인터넷에서 자료를 찾아보니...

윈도우 보다는 리눅스에서 트루타입 폰트 레스터라이져를 위해

사용하는 라이브러리 같더군요... 그래서 링크를 찾아보니

리눅스용 라이브러리가 가장먼저 눈에 뛰인듯...

 

윈도우용 라이브러리는 http://gnuwin32.sourceforge.net/packages/freetype.htm

여기서 다운받는걸로 되있습니다.

http://prdownloads.sourceforge.net/gnuwin32/freetype-2.1.10.exe?download

 

여기서 freetype-2.1.10.exe 이 파일을 받고 설치하면

윈도우용 프리타입 sdk를 사용할수 있습니다.

 

추가로 프리타입라이브러리를 사용하는 어플리케이션의 실행파일은

freetype6.dll, zlib1.dll을 같이 필요로 합니다.

 

흠... 윈도우용 튜토리얼을 처음에 찾아봤는데... 찾기 쉽지않더군요...

gpg랑 데브피아에도 없고... 그래서 dx의 텍스쳐에 바로

트루타입폰트를 찍는 예제를 만들어보았습니다.

 

아 아크로드가 이 프리타입라이브러리를 사용하더군요 보니깐.. ^^;;;

 

추신 - 이소스는 프리타입에 관한 가장기본적인 기능만 튜토리얼로 만들어본겁니다.

아직 손봐야할 기능들이 많이 있습니다.

 

더 참고하시고 싶은분은 위사이트 프리타입 튜토리얼을 참조하세요



반응형
반응형

잘 안나오네 , 아시는분 주소좀 찍어주세요~



http://wrice.egloos.com/m/5419686


게임 출시는 두달 정도 남은것 같지만 실제 개발은 다다음주면 끝입니다.
막바지 작업으로 최적화 작업을 하는 중이지요...

그런 이유로 요즘 PS3 용 라이브러리인 Edge 를 살펴보고 있습니다.
PS3 는 Vertex Shader 가 XBox360 보다 별로 힘을 못씁니다.

반면에 SPU 가 Vertex Shader 의 일을 할수 있도록 설계되어있습니다.
그리고 이렇게 Vertex Shader 의 기능을 사용하도록 도와주는 라이브러리가 바로 Edge 입니다. Sony 에서 개발해서 소스랑 예제랑 문서를 모두 함께 제공하고 있습니다. (라고는 해도 일반인에게 공개되어있지는 않은듯 합니다.)

사실 SPU 로 프로그래밍 하는것이 동기화 문제 때문에 까다롭습니다. 그래서 별로 사용할 일이 없는데 Edge 라이브러리를 보면 상당히 깔끔하게 SPU 를 활용할수 있도록 잘 짜여져 있는것 같습니다.

지금 시점에서, 최신 버전은 1.2 버전인데, 1.1.1 에서 1.2 로 넘어오면서 MLAA 기능을 사용할수 있도록 하고 있어서 매우 흥미롭습니다. 이번 프로젝트에서는 무리이지만 다음번 프로젝트에서는 꼭 사용해볼 예정입니다.

Edge 라이브러리로 가능한것들 중에는 압축/해제 라든지, Skinning, Animation 등이 있습니다.

반응형
반응형

BLOG main image


사용 예



calculate/check CRC32, MD5, SHA1, GOST, TTH, BTIH or other hash sums. 등이 포함되어있다





//Calculating SHA1 hash of a string

//const char* msg = "message digest";

const char* msg = "message digest";

unsigned char digest[64]={'\0',};

char output[130];



int res = rhash_msg(RHASH_CRC32, msg, strlen(msg), digest);

if(res < 0) {

fprintf(stderr, "hash calculation error\n");

return 1;

}


/* convert binary digest to hexadecimal string */

rhash_print_bytes(output, digest, rhash_get_digest_size(RHASH_SHA1), (RHPR_HEX | RHPR_UPPERCASE));

std::string dd= std::string(output,output+4);

//unsigned int data=  std::string(output,output+4);

printf("%s (\"%s\") = %s\n", rhash_get_name(RHASH_SHA1), msg, output);


}







http://rhash.anz.ru/


라이센스는 MIT 라이센스




Home    Download    Change Log    Manual    Hash Functions    Wiki    License ru | en 

RHash Program


RHash (Recursive Hasher) is a console utility for computing and verifying hash sums of files. It supports CRC32, MD4, MD5, SHA1, SHA256, SHA512, Tiger, DC++ TTH, BitTorrent BTIH, ED2K, AICH, GOST R 34.11-94, RIPEMD-160, HAS-160, EDON-R 256/512, Whirlpool and Snefru-128/256 algorithms. Hash sums are used to ensure and verify integrity of large volumes of data for a long-term storing or transferring.

Features:

  • Can calculate Magnet links.
  • Output in a predefined (SFV, BSD-like) or user defined format.
  • Ability to process directories recursively.
  • Updating of existing hash files (adding sums of files missing in the hash file).
  • Calculates several hash sums in one pass.
  • Portability: the program works the same under Linux, *BSD, or Windows.

RHash is written in pure C, small in size and is distributed under Open Source License.

Support This ProjectDownload RHash.

반응형
반응형

http://anster.egloos.com/2165172



오늘, 그리고 지난 주 금요일은 하루종일 압축 라이브러리와 씨름했다.

맨 처음에는 Zip으로 압축할려고 찾아봤더니, Zlib를 약간 개량한 Zziplib 란게 나왔는데,, 도저히 빌드 못하겠다.. 그래서 포기.

Zlib 는 사용할려고 기껏 빌드했더니,, 유니코드 지원이 안되더라. 

그래서 구글에서 유니코드를 지원하는 zlib 검색을 해보니 코드프로젝트에 등록되어있는 CGzip이 나왔다. 오. 사용법도 쉽고 간단하구만,, 해서 받고 압축 풀고 각종 에러를 해결하고 빌드하니 파일 하나만 압축이 가능하댄다 -_-; 제작자가 시간이 없어서 여러개를 압축하는데까지는 신경을 못썼댄다.

결국 코드프로젝트에서 LiteZip 이란 라이브러리를 찾아냈다. 찾아내서 압축을 풀고 보니 VC++ 5.0 프로젝트 워크스페이스가 나온다.
2010으로는 바로 변경 불가 -_-; 그래서 6.0으로 변환 후 다시 2010으로 변환. 

파일 내부의 소스를 보니 WIN32인 경우와 아닌 경우를 나누어 놓았던데,, 리눅스 호환 라이브러리다. 윈도우와 리눅스의 경우 두 경우 모두 컴파일 할 수 해 놓은 라이브러리인데, 굉장히 정교하게 짜여졌다는 느낌을 많이 받았다. 나도 이렇게 유용하고, 잘 설계된 라이브러리를 만들고 싶다.^^


아참, 그리고 LiteZip.h 에 다음과 같은 문장을 추가 해 주어야 한다.

// Edited 2011. 07. 18 By Anster.
// Functions for adding a "Directory" to a ZIP archive

DWORD WINAPI ZipAddDirA(HZIP, const char*, DWORD);
DWORD WINAPI ZipAddDirW(HZIP, const WCHAR* DWORD);

#ifdef UNICODE
#define ZipAddDir ZipAddDirW
typedef DWORD WINAPI ZipAddDirPtr(HZIP, const WCHAR*, DWORD);
#define ZIPADDDIRNAME "ZipAddDirW"
#else
#define ZipAddDir ZipAddDirA
typedef DWORD WINAPI ZipAddDirPtr(HZIP, const char*, DWORD);
#define ZIPADDDIRNAME "ZipAddDirA"
#endif

이 라이브러리의 설계자가 후에 디렉터리를 압축하는 함수(ZipAddDirA, W)을 라이브러리에 추가하면서
라이브러리에 함수를 익스포트 해 놓았으나 헤더파일에는 원형을 추가하지 않아서 사용하려면 빌드 에러가 난다.



2011. 7. 19 추가 

-_- 사용하다보니, 멀티바이트 버전의 ZipAddDirA 는 잘 작동하는데, ZipAddDirW 가 작동하지 않는다. 라이브러리를 내가 직접 고쳐서 써야하는것도 정말 너무너무 귀찮고 -_-;; 찾다보니 라이브러리가 아니라 CPP와 헤더파일로 첨부만 해서 함수를 사용하는 

Zip Utils 를 찾아냈다. zip_utils_src.zip

Clean, Elegant, Simple 한 C++/Win32 라이브러리라는데,, 이거마저 안되면 다른걸 또 찾아야된다 -_-


참고 - CGzip Lib http://www.codeproject.com/KB/cpp/cgzip.aspx
         LiteZip LIb http://www.codeproject.com/KB/library/LiteZip.aspx
         Zip Utils http://www.codeproject.com/KB/files/zip_utils.aspx
         Zip http://www.codeproject.com/KB/recipes/zip.aspx
         Boost Gzip http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/classes/gzip.html
         Boost Zlib http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/classes/zlib.html
         Boost Bzip2 http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/classes/bzip2.html#examples
         Minizip http://www.winimage.com/zLibDll/minizip.html
         Minizip Example http://ddiggam.tistory.com/5

2011. 07. 21 추가

Zlib 압축 알고리즘과 Zip(PKZIP) 압축 알고리즘이 같아서 헤더 포맷만 맞추어주면 Zlib를 Zip 압축에 쓸수 있다고 한다.

참고 -  http://www.google.co.kr/url?sa=t&source=web&cd=3&ved=0CD0QFjAC&url=http%3A%2F%2Fkldp.org%2Fnode%206&ei=1LknTpmkAeydmQWMkvH_CQ&usg=AFQjCNF_WrrqYyFQRCWOYmAvk6wfpSADiQ

그리고 ZIP Utils 을 사용해서 압축을 하면 한글 파일과 폴더가 이상한 이름으로(like as 꽯꽥) 압축이 되는데, 

이는 헤더인 zip.h 와 unzip.h 를 수정하면 된다. CP_UTF8 -> CP_OEM 으로 변경하자. 

아래는 폴더를 압축하기 쉽게끔 만든 파일이다. 

CompressDirectory.cpp

다음과 같이 사용하면 된다.


#include <stdafx.h>
#include <zip.h>

BOOL SetCompressDirectory (HZIP* phZip, LPTSTR pszCompressPath, LPTSTR pszZipCreationPath, LPTSTR pszZipName );

int _tmain(int argc, _TCHAR* argv[])
{
    if (argc < 4)
        return 0;

    HZIP hZip;

    if ( !SetCompressDirectory ( &hZip, argv[1], argv[2], argv[3] ) )
        _tprintf ( _T("FAIL\n") );
    else
        _tprintf ( _T("SUCCESS\n") );

    return 0;
}


반응형
반응형

http://loki-lib.sourceforge.net/index.php?n=Main.Download



Download

Get the latest release from
 
Check out the most recent code, SVN howto at

Source code for "Modern C++ Design"

Download the source code of the book from:

Andrei's articles

Have a look at Andrei's articles.

반응형
반응형

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html




gakushin logo

SFMT logo

SIMD-oriented Fast Mersenne Twister (SFMT):
twice faster than Mersenne Twister*1.

Japanese Version

News

LINK

What is SFMT?

SFMT is a new variant of Mersenne Twister (MT) introduced by Mutsuo Saito and Makoto Matsumoto in 2006. The algorithm was reported atMCQMC 2006. The article published in the proceedings of MCQMC2006. (see Prof. Matsumoto's Papers on random number generation.) SFMT is a Linear Feedbacked Shift Register (LFSR) generator that generates a 128-bit pseudorandom integer at one step. SFMT is designed with recent parallelism of modern CPUs, such as multi-stage pipelining and SIMD (e.g. 128-bit integer) instructions. It supports 32-bit and 64-bit integers, as well as double precision floating point as output.

SFMT is much faster than MT, in most platforms. Not only the speed, but also the dimensions of equidistributions at v-bit precision are improved. In addition, recovery from 0-excess initial state is much faster. See Master's Thesis of Mutsuo Saito for detail.

The following implementation SFMT19937 can be compiled in three possible platforms:

  1. Standard C without SIMD instructions
  2. CPUs with Intel's SSE2 instructions + C compiler which supports these feature
  3. CPUs with PowerPC's AltiVec instructions + C compiler which supports these feature

In each platform, SFMT has better performance than MT: see comparison of speed.

We put tables of equidistribution of SFMT. They are 32bit and 64bit.

Download SFMT which supports various periods from 2607-1 to 2216091-1

This code is released on January 31st in 2007, so it may contain some bugs. Any feedback is welcome (send an email to Mutsuo Saito, saito "at sign" math.sci.hiroshima-u.ac.jp and m-mat "at sign" math.sci.hiroshima-u.ac.jp)

versionarchivechanges
new!1.4SFMT-src-1.4.zip
SFMT-src-1.4.tar.gz
internal state of SFMT is kept in structure. function and macro names are changed to have sfmt_ prefix. This version can work with SFMT-jump. ALTIVEC OR BIGENDIAN ARE NOT TESTED AT ALL. (2012/6/28)
1.3.3SFMT-src-1.3.3.zip
SFMT-src-1.3.3.tar.gz
change not to compile do_recursion function when SSE2 or ALTIVEC is specified. This is to avoid compiler warning. (2007/10/6)
1.3.2SFMT-src-1.3.2.zip
SFMT-src-1.3.2.tar.gz
Fix bug about to_res53_mix() and genrand_res53_mix(). (2007/8/20)
1.3.1SFMT-src-1.3.1.zip
SFMT-src-1.3.1.tar.gz
Fix bug about compile error in MSC. Add two functions to_res53_mix() and genrand_res53_mix(). Change optimization option of gcc from -O9 to -O3. Add MSC __forceinline option. (2007/8/12)
1.3SFMT-src-1.3.zip
SFMT-src-1.3.tar.gz
Add support for the period 2216091-1. BUG fixed about BIG ENDIAN. Add parameter data for parallel generation. Support AltiVec on OSs which are not osx. (2007/6/2)
1.2SFMT-src-1.2.zip
SFMT-src-1.2.tar.gz
Now, various periods form 2607-1 to 2132049-1 are supported. The source code is combined. The second argument of vec_perm function is casted. (2007/3/1)
1.1sfmt19937src-1.1.zip
sfmt19937src-1.1.tar.gz
The period certification method is changed from constant to function. Makefile and documents changed. (2007/1/31)
1.0sfmt19937src-1.0.zip
sfmt19937src-1.0.tar.gz
First version.

If you have some trouble to download, try this page.

Double precision SIMD-oriented Fast Mersenne Twister (dSFMT)

The purpose of dSFMT is to speed up the generation by avoiding the expensive conversion of integer to double (floating point). dSFMT directly generates double precision floating point pseudorandom numbers which have the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985) format. dSFMT is only available on the CPUs which use IEEE 754 format double precision floating point numbers.

dSFMT doesn't support integer outputs. dSFMT supports the output of double precision floating point pseudorandom numbers which distribute in the range of [1, 2), [0, 1), (0, 1] and (0, 1). And it also supports the various periods form 2607-1 to 2132049-1. (dSFMT ver. 2.1 supports the periods from 2521-1 to 2216091-1.)

This code is released on March 12th in 2007, so it may contain some bugs. Any feedback is welcome (send an email to Mutsuo Saito, saito"at sign" math.sci.hiroshima-u.ac.jp and m-mat "at sign" math.sci.hiroshima-u.ac.jp)

The algorithm was reported at MCQMC 2008. This is the slide PDF file we used for the talk.
The article published in the proceedings of MCQMC2008. (see Prof. Matsumoto's Papers on random number generation.)

versionarchivechanges
new!2.2.1dSFMT-src-2.2.1.zip
dSFMT-src-2.2.1.tar.gz
Definitions of Shift constant in AltiVec were changed. They had not been fit to the instruction set architecture of AltiVec. (2013/2/21)
2.2dSFMT-src-2.2.zip
dSFMT-src-2.2.tar.gz
The initialization of the constants for sse2 is changed. dSFMT-common.h is created. This version can work with dSFMT Jump function. (2012/6/29)
2.1dSFMT-src-2.1.zip
dSFMT-src-2.1.tar.gz
This version supports the periods from 2521-1 to 2216091-1. We added new function dsfmt_genrand_uint32, which returns 32-bit unsigned integer. If you need many floating point pseudo random numbers and a few integers, you don't need to use another integer generator. (2009/4/18)
2.0dSFMT-src-2.0.zip
dSFMT-src-2.0.tar.gz
The recursion formula of dSFMT is changed. The supported periods are changed. The output sequences are completely changed. The generation speed is improved. The variable for initialization check is removed, because it causes an execution error in cygwin. dSFMT ver. 2.0 supports the periods from 2521-1 to 219937-1 currently. dSFMT ver. 2.0 is developed for higher speed. No serious problems are reported for dSFMT ver. 1.xx. (2008/8/26)
1.3dSFMT-src-1.3.zip
dSFMT-src-1.3.tar.gz
use structure of C language. bug fix about checking BIG_ENDIAN. Function names are changed to have the prefixdsfmt_, but old names are also available. (2008/2/28)
1.2.1dSFMT-src-1.2.1.zip
dSFMT-src-1.2.1.tar.gz
add #include <altivec.h> to dSFMT.c. (2007/8/29)
1.2dSFMT-src-1.2.zip
dSFMT-src-1.2.tar.gz
CAUTION: dSFMT.xxx.out.txt is changed. Bug fixed in test.c about printf precision specifier. Larger period 2216091-1 is supported. gcc compile option changed form -O9 to -O3. Add AltiVec parameter format for systems which are not OSX. Change Makefile for systems which are not OSX and support AltiVec. Change sample2 of howto-compile for Free BSD. Change period certification code more smart. Change source files for BORLANDC and Visual Studio. (2007/8/22)
1.1dSFMT-src-1.1.zip
dSFMT-src-1.1.tar.gz
Larger period 2132049-1 is supported. A bug about BIG ENDIAN machine is fixed. Some important bugs are fixed, but there is no influence to the outputs. Source codes were refactored. (2007/3/22)
1.0dSFMT-src-1.0.zip
dSFMT-src-1.0.tar.gz
The first version. (2007/3/12)

If you have some trouble to download, try this page.

CPUs and compilers for SFMT optimized for SIMD

SIMD typeCPUsgcc optiongcc version
SSE2Intel: Pentium M, Pentium 4, core, core 2, etc
AMD: Athlon 64, Sempron, Turion 64, etc
see Wikipedia SSE2:CPUs supporting SSE2
-msse23.4 or later
AltiVecPowerPC G4, G5-faltivec3.3 or later

See also How to compile SFMT.

License

SFMT, as well as MT, can be used freely for any purpose, including commercial use. See LICENSE.txt for detail.

.

Back to Mersenne Twister Home Page


*1 This work is supported in part by JSPS Core-to-Core Program No. 18005: "New Developments of Arithmetic Geometry, Motive, Galois Theory, and Their Practical Applications." 
This work is also partially supported by JSPS Grant-in-Aid for Scientific Research No. 16204002, No. 19204002 and No. 18654021.

반응형
반응형
http://blog.tcltk.co.kr/?p=962


MFC/ wxWidgets plot 라이브러리 정리

MFC

ChartDirector
multiaxes_p

http://www.advsofteng.com/index.html

다양한 차트와 그래프를 지원한다. 최고의 라이브러리이다.

Cplot
cplot_2window_50
http://cplot.sourceforge.net/

PGL(Plot Graphic Library)
pgl

http://www.pelikhan.com/
http://sourceforge.net/projects/pglmfclib/
http://www.codeproject.com/KB/miscctrl/pgllib.aspx

훌륭한 플롯 라이브러리지만 아쉽게도 상용버전이다.

Rt-Plot
GraphWindow

http://www.rt-science.de/rt-plot.html

wxWidgets

wxPlotCtrl
image

http://wxcode.sourceforge.net/showcomp.php?name=wxPlotCtrl

wxMathPlot
wxmp9

http://wxmathplot.sourceforge.net/

wxChart
image2

http://wxcode.sourceforge.net/components/wxchart/

Projectile 
screenshot

http://sourceforge.net/projects/projectilecalc/

반응형
반응형

http://www.codeproject.com/KB/applications/visualleakdetector.aspx

D:\Program Files\Visual Leak Detector\README.html








Visual Leak Detector 1.9d (Beta)

Enhanced Memory Leak Detection for Visual C++

Introduction

Visual C++ provides built-in memory leak detection, but its capabilities are minimal at best. This memory leak detector was created as a free alternative to the built-in memory leak detector provided with Visual C++. Here are some of Visual Leak Detector's features, none of which exist in the built-in detector:

  • Provides a complete stack trace for each leaked block, including source file and line number information when available.
  • Detects most, if not all, types of in-process memory leaks including COM-based leaks, and pure Win32 heap-based leaks.
  • Selected modules (DLLs or even the main EXE) can be excluded from leak detection.
  • Provides complete data dumps (in hex and ASCII) of leaked blocks.
  • Customizable memory leak report: can be saved to a file or sent to the debugger and can include a variable level of detail.

Other after-market leak detectors for Visual C++ are already available. But most of the really popular ones, like Purify and BoundsChecker, are very expensive. A few free alternatives exist, but they're often too intrusive, restrictive, or unreliable. Visual Leak Detector is currently the only freely available memory leak detector for Visual C++ that provides all of the above professional-level features packaged neatly in an easy-to-use library.

Visual Leak Detector is licensed free of charge as a service to the Windows developer community. If you find it to be useful and would like to just say "Thanks!", or you think it stinks and would like to say "This thing sucks!", please feel free to drop me a note. Or, if you'd prefer, you can contribute a small donation. Both are very appreciated.

Using Visual Leak Detector

This section briefly describes the basics of using Visual Leak Detector (VLD).

Important! : Before using VLD with any Visual C++ project, you must first add the Visual Leak Detector include and library directories to the Visual C++ include and library directory search paths:

  • Visual C++ 8: Go to Tools -> Options -> Projects and Solutions -> VC++ Directories. Select "Include files" from the "Show Directories For" drop-down menu. Add the include subdirectory from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select "Library files" from the drop-down menu and add the lib subdirectory from the Visual Leak Detector installation directory. Again, move it to the bottom of the list.
  • Visual C++ 7: Go to Project Properties -> C/C++ -> General -> Additional Include Directories and add the include subdirectory from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select Additional Library Directories and add the lib subdirectory from the Visual Leak Detector installation directory. Again, move it to the bottom of the list.
  • Visual C++ 6: Go to Tools -> Options -> Directories. Select "Include files" from the "Show Directories For" drop-down menu. Add the include subdirectory from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select "Library files" from the drop-down menu and add the lib subdirectory from the Visual Leak Detector installation directory. Again, move it to the bottom of the list.

To use VLD with your project, follow these simple steps:

  1. In at least one C/C++ source file from your program, include the vld.h header file. It should not matter which file you add the include statement to. It also should not matter in what order the header is included in relation to other headers. The only exception is stdafx.h (or any other precompiled header). A precompiled header, such as stdafx.h, must always be the first header included in a source file, so vld.h must be included after any precompiled headers.
  2. If your program contains one or more DLLs that you would also like to check for memory leaks, then also include vld.h in at least one source file from each DLL to be included in leak detection.
  3. Build the debug version of your program.

Note: Unlike earlier versions of VLD, it is now acceptable to include vld.h in every source file, or to include it in a common header that is included by many or all source files. Only one copy of the VLD code will be loaded into the process, regardless of how many source files include vld.h.

VLD will detect memory leaks in your program whenever you run the debug version. When you run the program under the Visual C++ debugger, a report of all the memory leaks detected will be displayed in the debugger's output window when your program exits (the report can optionally be saved to a file instead, see ReportFile under Configuration Options). Double-clicking on a source file's line number in the memory leak report will take you to that file and line in the editor window, allowing easy navigation of the code path leading up to the allocation that resulted in the memory leak.

Note: When you build release versions of your program, VLD will not be linked into the executable. So it is safe to leave vld.h included in your source files when doing release builds. Doing so will not result in any performance degradation or any other undesirable overhead.

Configuration Options

There are a several configuration options that control specific aspects of VLD's operation. These configuration options are stored in the vld.ini configuration file. By default, the configuration file should be in the Visual Leak Detector installation directory. However, the configuration file can be copied to the program's working directory, in which case the configuration settings in that copy of vld.ini will apply only when debugging that one program.

AggregateDuplicates

Normally, VLD displays each individual leaked block in detail. Setting this option to "yes" will make VLD aggregate all leaks that share the same size and call stack under a single entry in the memory leak report. Only the first leaked block will be reported in detail. No other identical leaks will be displayed. Instead, a tally showing the total number of leaks matching that size and call stack will be shown. This can be useful if there are only a few sources of leaks, but those few sources are repeatedly leaking a very large number of memory blocks.

ForceIncludeModules

In some rare cases, it may be necessary to include a module in leak detection, but it may not be possible to include vld.h in any of the module's sources. In such cases, this option can be used to force VLD to include those modules in leak detection. List the names of the modules (DLLs) to be forcefully included in leak detection. If you do use this option, it's advisable to also add vld.lib to the list of library modules in the linker options of your project's settings.

Caution: Use this option only when absolutely necessary. In some situations, use of this option may result in unpredictable behavior including false leak reports and/or crashes. It's best to stay away from this option unless you are sure you understand what you are doing.

MaxDataDump

Set this option to an integer value to limit the amount of data displayed in memory block data dumps. When this number of bytes of data have been dumped, the dump will stop. This can be useful if any of the leaked blocks are very large and the debugger's output window becomes too cluttered. You can set this option to 0 (zero) if you want to suppress data dumps altogether.

MaxTraceFrames

By default, VLD will trace the call stack for each allocated block as far back as possible. Each frame traced adds additional overhead (in both CPU time and memory usage) to your debug executable. If you'd like to limit this overhead, you can define this macro to an integer value. The stack trace will stop when it has traced this number of frames. The frame count may include some of the "internal" frames which, by default, are not displayed in the debugger's output window (see TraceInternalFrames below). In some cases there may be about three or four "internal" frames at the beginning of the call stack. Keep this in mind when using this macro, or you may not see the number of frames you expect.

ReportEncoding

When the memory leak report is saved to a file, the report may optionally be Unicode encoded instead of using the default ASCII encoding. This might be useful if the data contained in leaked blocks is likely to consist of Unicode text. Set this option to "unicode" to generate a Unicode encoded report.

ReportFile

Use this option to specify the name and location of the file in which to save the memory leak report when using a file as the report destination, as specified by the ReportTo option. If no file is specified here, then VLD will save the report in a file named "memory_leak_report.txt" in the working directory of the program.

ReportTo

The memory leak report may be sent to a file in addition to, or instead of, the debugger. Use this option to specify which type of destination to use. Specify one of "debugger" (the default), "file", or "both".

SelfTest

VLD has the ability to check itself for memory leaks. This feature is always active. Every time you run VLD, in addition to checking your own program for memory leaks, it is also checking itself for leaks. Setting this option to "on" forces VLD to intentionally leak a small amount of memory: a 21-character block filled with the text "Memory Leak Self-Test". This provides a way to test VLD's ability to check itself for memory leaks and verify that this capability is working correctly. This option is usually only useful for debugging VLD itself.

SlowDebuggerDump

If enabled, this option causes Visual Leak Detector to write the memory leak report to the debugger's output window at a slower than normal rate. This option is specifically designed to work around a known issue with some older versions of Visual Studio where some data sent to the output window might be lost if it is sent too quickly. If you notice that some information seems to be missing from the memory leak report, try turning this on.

StackWalkMethod

Selects the method to be used for walking the stack to obtain call stacks for allocated memory blocks. The default "fast" method may not always be able to successfully trace completely through all call stacks. In such cases, the "safe" method may prove to be more reliable in obtaining the full stack trace. The disadvantage with the "safe" method is that it is significantly slower than the "fast" method and will probably result in very noticeable performance degradation of the program being debugged. In most cases it should be okay to leave this option set to "fast". If you experience problems getting VLD to show call stacks, you can try setting this option to "safe".

If you do use the "safe" method, and notice a significant performance decrease, you may want to consider using the MaxTraceFrames option to limit the number of frames traced to a relatively small number. This can reduce the amount of time spent tracing the stack by a very large amount.

StartDisabled

Set this option to "yes" to disable memory leak detection initially. This can be useful if you need to be able to selectively enable memory leak detection from runtime, without needing to rebuild the executable; however, this option should be used with caution. Any memory leaks that may occur before memory leak detection is enabled at runtime will go undetected. For example, if the constructor of some global variable allocates memory before execution reaches a subsequent call to VLDEnable, then VLD will not be able to detect if the memory allocated by the global variable is never freed. Refer to the following section on controlling leak detection at runtime for details on using the runtime APIs which can be useful in conjunction with this option.

TraceInternalFrames

This option determines whether or not all frames of the call stack, including frames internal to the heap, are traced. There will always be a number of frames on the call stack which are internal to Visual Leak Detector and C/C++ or Win32 heap APIs that aren't generally useful for determining the cause of a leak. Normally these frames are skipped during the stack trace, which somewhat reduces the time spent tracing and amount of data collected and stored in memory. Including all frames in the stack trace, all the way down into VLD's own code can, however, be useful for debugging VLD itself.

Controlling Leak Detection at Runtime

Using the default configuration, VLD's memory leak detection will be enabled during the entire run of your program. In certain scenarios it may be desirable to selectively disable memory leak detection in certain segments of your code. VLD provides simple APIs for controlling the state of memory leak detection at runtime. To access these APIs, include vld.h in the source file that needs to use them.

VLDDisable

This function disables memory leak detection. After calling this function, memory leak detection will remain disabled until it is explicitly re-enabled via a call to VLDEnable.

void VLDDisable (void);

Arguments:

This function accepts no arguments.

Return Value:

None (this function always succeeds).

Notes:

This function controls memory leak detection on a per-thread basis. In other words, calling this function disables memory leak detection for only the thread that called the function. Memory leak detection will remain enabled for any other threads in the same process. This insulates the programmer from having to synchronize multiple threads that disable and enable memory leak detection. However, note also that this means that in order to disable memory leak detection process-wide, this function must be called from every thread in the process.

VLDEnable

This function enables memory leak detection if it was previously disabled. After calling this function, memory leak detection will remain enabled unless it is explicitly disabled again via a call to VLDDisable().

void VLDEnable (void);

Arguments:

This function accepts no arguments.

Return Value:

None (this function always succeeds).

Notes:

This function controls memory leak detection on a per-thread basis. See the remarks for VLDDisable regarding multithreading and memory leak detection for details. Those same concepts also apply to this function.

Building Visual Leak Detector from Source

Because Visual Leak Detector is open source, it can be built from source if you want to tweak it to your liking. The most difficult part about building VLD from source is getting your build environment correctly set up. But if you follow these instructions carefully, the process should be fairly painless.

  1. VLD depends on the Debug Help Library. This library is part of Debugging Tools for Windows (DTfW). Download and install DTfW in order to install the required headers and libraries. I recommend installing version 6.5 of DTfW. Newer versions may also work, but older versions will probably not work. Be sure to manually select to install the SDK files during the DTfW installation or the headers and libraries will not be installed (they are not installed with a default installation).
  2. Visual C++ will need to be made aware of where it can find the Debug Help Library header and library files. Add the sdk\inc and sdk\lib subdirectories from the DTfW installation directory to the include and library search paths in Visual C++. (See the section above on using Visual Leak Detector on instructions for adding to these search paths).
  3. VLD also requires a reasonably up-to-date Platform SDK. It is known to work with the latest SDK (as of this writing) which is the Windows Server 2003 R2 SDK. It should also work with earlier SDKs, such as the Windows XP SP2 SDK or may even work with SDKs as old as the February 2003 SDK. If in doubt, update your Platform SDK to the latest version.
  4. Again, Visual C++ will need to know where to find the Platform SDK headers and libraries. Add the Include and Lib subdirectories from the Platform SDK installation directory to the Include and Library search paths, respectively. The Platform SDK directories should be placed just after the DTfW directories.

To summarize, your Visual C++ include search path should look something like this:

  • C:\Program Files\Debugging Tools for Windows\sdk\inc
  • C:\Program Files\Microsoft Platform SDK\Include
  • C:\Program Files\Microsoft Visual Studio\VCx\Include
  • ...

And your Visual C++ library search path should look like this:

  • C:\Program Files\Debugging Tools for Windows\sdk\lib
  • C:\Program Files\Microsoft Platform SDK\Lib
  • C:\Program Files\Microsoft Visual Studio\VCx\Lib
  • ...

In the above examples, "VCx" could be "VC", "VC7", or "VC98" (or possibly other values) depending on which version of Visual Studio you have installed. Also, the name of your Platform SDK directory will probably be different from the example depending on which version of the Platform SDK you have installed.

Once you have completed all of the above steps, your build environment should be ready. To build VLD, just open the vld.sln solution file and do a full build.

Windows x64 Support

The VLD source code has been modified to add support for x64-based 64-bit Windows. However, the binary contained in the distributed version of VLD is 32-bit only. To take advantage of the 64-bit support, you'll need to build a 64-bit version of VLD from source. To build the 64-bit version, follow the instructions for building VLD from source. So long as it is built using a x64-compatible compiler in 64-bit mode, the resulting DLL will be a 64-bit binary.

Note: I have not personally tested the 64-bit extensions so they are not absolutely guaranteed to work out-of-the-box. There may be a few lingering 64-bit compiler errors that still need to be worked out. If you need 64-bit support and run into problems trying to build the source in 64-bit mode, please let me know. I'll be glad to assist in getting the 64-bit code working properly.

Frequently Asked Questions

When I try to compile my program with VLD, it fails and the compiler gives this error: Cannot open include file: 'vld.h': No such file or directory.

The compiler can't find the header file that VLD installed. This probably means that VLD's include subdirectory has not been added to the Visual C++ include search path. See the section above about Using Visual Leak Detector for instructions on how to add VLD's directories to the search path.

In the memory leak report, the callstack contains many lines that say "File and line number unvailable" or "Function name unavailable".

This may mean that VLD couldn't find the symbol database for your program. The symbol database is ususally in a file named [my-program-name].pdb. If this file is not located in the same directory as the program itself, then VLD will probably not find it and can't show any file or function names.

When running my program with VLD, I get an error message saying, "ERROR: Visual Leak Detector: Unable to load dbghelp.dll".

VLD can't find the copy of the Debug Help Library that was installed with it. Your installation might be corrupt. Try uninstalling and reinstalling VLD.

Known Restrictions

Known restrictions/limitations in this version of VLD include:

  • Memory allocations made through calls to functions loaded from a DLL using delayed loading may not be detected.
  • Support for programs that use MFC 7.0 or MFC 7.1 is not complete yet. Some memory leaks from such MFC-based programs may not be detected. A possible workaround for this restriction is to try forcefully including the MFC DLLs in memory leak detection, by setting the ForceIncludeModules configuration option to: "mfc70d.dll mfc71d.dll" and explicitly adding vld.lib as an input file on the linker command line (can be added through project settings by adding it to the list of library modules in the linker options). This restriction does not apply to programs that use MFC 4.2 or MFC 8.0 which are both fully supported.
  • On Windows 2000 and earlier operating systems, you may need to manually add the [Visual Leak Detector Installation Directory]\bin\Microsoft.VC80.CRT directory to the system PATH environment variable. Otherwise the system may not find the required msvcr80.dll DLL when running VLD.

License

Visual Leak Detector is distributed under the terms of the GNU Lesser General Public License. This license allows you to use the VLD library with your own programs without restriction. However, if you build a program (or another library) that is based on the VLD source code, or uses parts of the VLD source code in it, then some restrictions will apply. What this means is that you are free to ship and use the distributed version of the VLD DLL with regular commercial programs. But if you create a modified version of VLD, that modified version must remain "free software". See the COPYING.txt file for details.

The Debug Help Library (dbghelp.dll) distributed with this software is not part of Visual Leak Detector and is not covered under the terms of the GNU Lesser General Public License. It is a separately copyrighted work of Microsoft Corporation. Microsoft reserves all its rights to its copyright in the Debug Help Library. Neither your use of the Visual Leak Detector software, nor your license under the GNU Lesser General Public license grant you any rights to use the Debug Help Library in ANY WAY (for example, redistributing it) that would infringe upon Microsoft Corporation's copyright in the Debug Help Library.

NO WARRANTY

BECAUSE VISUAL LEAK DETECTOR ("THE SOFTWARE") IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE LICENSING TERMS SET FORTH ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Contacting the Author

Please forward any bug reports, questions, comments or suggestions to me atdmoulding@gmail.com.

Donations to help support ongoing development of Visual Leak Detector are very appreciated!

Valid XHTML 1.0!Valid CSS!

반응형

+ Recent posts