2012년 4월 9일 월요일

7-zip을 기본 압축 프로그램으로 설정

7-Zip File Manager를 마우스 오른쪽 버튼으로 클릭하고, 팝업 메뉴에서 '관리자 권한으로 실행'을 눌러 관리자 권한으로 실행시킵니다.


7-Zip의 도구 모음에서 '도구'메뉴를 누르고, '옵션'을 선택합니다. 이제, '모두 선택'과 '적용'버튼을 차례로 클릭합니다.

2012년 2월 29일 수요일

Eclipse용 SVN(Subclipse) 업데이트 사이트

http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA

Current Release

Eclipse 3.2/Callisto, 3.3/Europa, 3.4/Ganymede, 3.5/Galileo, 3.6/Helios, 3.7/Indigo, +

Subclipse 1.8.5 and 1.6.18 and 1.4.8 are now available for Eclipse 3.2+!
See the changelog for details. Existing Subclipse users should read the upgrade instructions for important information on changes you to need to make to your Eclipse preferences to see the new version in the update manager.
Subclipse 1.4.x includes and requires Subversion 1.5.x client features and working copy format.
Subclipse 1.6.x includes and requires Subversion 1.6.x client features and working copy format.
Subclipse 1.8.x includes and requires Subversion 1.7.x client features and working copy format.
Links for 1.8.x Release:
Changelog: http://subclipse.tigris.org/subclipse_1.8.x/changes.html
Eclipse update site URL: http://subclipse.tigris.org/update_1.8.x
Zipped downloads: http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240
Links for 1.6.x Release:
Changelog: http://subclipse.tigris.org/subclipse_1.6.x/changes.html
Eclipse update site URL: http://subclipse.tigris.org/update_1.6.x
Zipped downloads: http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240
Links for 1.4.x Release:
Changelog: http://subclipse.tigris.org/subclipse_1.4.x/changes.html
Eclipse update site URL: http://subclipse.tigris.org/update_1.4.x
Zipped downloads: http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240


서버 : http://blog.jidolstar.com/552 , http://kkamagui.springnote.com/pages/585605
서버 다운로드 : http://www.visualsvn.com/downloads/

클라이언트 : http://ioriy2k.pe.kr/archives/291
클라이언트 다운로드 : http://tortoisesvn.net/downloads.html

2012년 2월 23일 목요일

Purify - 미들웨어에서 호출한 서비스 적용방법

Purify를 통해서 미들웨어에서 호출된 서비스를 검증하는 방법은 대략 아래와 같습니다.
--------------------------------------------------
1> 서비스 원본의 복사본을 만듬, 례를 들어 서비스 파일이 sample_service라면 sample_service.nopure로 복사하여 저장함
2> Purify로 서비스 실행 파일 sample_service를 instrument 하여 sample_service.pure를 생성함, 례를 들면
# purify -verbose -log-file=/tmp/sample_service.purify.log -cache-dir=/tmp/purify-cache -always-use-cache-dir sample_service > verbose-log 2>&1
위에 커만드라인에 보이는 옵션들은 online 설명을 참고하시기 바랍니다.
3> Instrument한 서비스 파일sample_service.pure를 원본 서비스 파일 이름sample_service으로 바꿈
4> 미들웨어를 실행하여 서비스를 호출하고 서비스 기능들을 사용하시면 Purify가 데이터를 수집함
5> 미들웨어를 중지
6> 앞에 복사 저장한 sample_service.nopure 파일을 이용하여 서비스 파일을 원본으로 복원함
---------------------------------------------------

2012년 1월 31일 화요일

EGit 설치 및 사용자 가이드


  • 설치

http://eclipse.org/egit/download/ 에 p2 repository를 이클립스 update site에 추가하여 설치를 합니다.


  • 사용자 가이드

http://wiki.eclipse.org/EGit/User_Guide


2012년 1월 12일 목요일

TESTRT - TP.dll 또는 TP.so 사용법


* c/cpp 혼합인 경우에 쓸수 있는 환경변수
    ATL_FORCE_C         is off (default)
    ATL_FORCE_CPLUSPLUS is off (default)
    ATL_FORCE_C_TDP     is off (default)

* tp.dll 또는 tp.so 등 공유라이브러리 사용시 쓸수 있는 환경변수
    ATL_NO_TDP_COMPILE  is off (default)
    ATL_SHARED_TDP      is off (default)

ATL_NO_TDP_COMPILE
If set, the Target Deployment Port Library is never compiled, even at link time
ATL_SHARED_TDP
If set and used in conjunction with ATL_NO_TDP_COMPILE, it must contain
the name of the shared library containing the TP.o[bj] file to be put
in place of TP.o[bj] on the link command line

1) attolcc를 사용하는 경우 예제
On Suse 7.2 or RedHat 7.2
cmd> attolcc -force_tdp_cc --cflags=-fPIC
cmd> ld -shared -rpath `pwd` TP.o -o TP.so
cmd> export ATL_NO_TDP_COMPILE=on
cmd> export ATL_SHARED_TDP=TP.so
cmd> attolcc -- cc -g -o toto toto.c
cmd> ldd ./toto
TP.so => TP.so (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x40039000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

On SuSe 8.0
cmd> attolcc -force_tdp_cc --cflags=-fPIC
cmd> ld -Wl,-rpath,. TP.o -o TP.so
cmd> export ATL_NO_TDP_COMPILE=on
cmd> export ATL_SHARED_TDP=TP.so
cmd> attolcc -- cc -g -o toto toto.c
cmd> ldd ./toto
TP.so => TP.so (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x40039000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

2) 일반적인 빌드 경우 예제 - 다소 옛날식...

[build.bat]
------------------------------------------------------------------------
del *.exe *.dll *.obj *.fdc *.tsf *.tpf *.tqf *.tdf *.tio *.spt *.pdb *.ilk *.lib *.idb *.exp Products.h
set CC=cl /MDd /Zi  
set LD=link /INCREMENTAL:NO /debug

rem compil the dll sources
%CC% -c mydll.cpp
%CC% -c mydll2.cpp

rem generate the dll
%LD% /dll /machine:I386 /out:"mydll.dll"  mydll.obj
%LD% /dll /machine:I386 /out:"mydll2.dll" mydll2.obj

rem compil the main application
%CC% -c example.c

rem link the main app with its dll
%LD% example.obj

rem run app without any instrumentation
example.exe
pause

del *.exe *.dll *.obj *.pdb *.ilk *.lib *.idb *.exp

rem do the same thing with instrumentation
set ATLTGT=%TESTRTDIR%\targets\cvisual6
set OPTIONS=-proc=ret -block=implicit -mempro
set CC=%ATLTGT%\cmd\attolcc %OPTIONS% -verbose -force_tdp_cc -- %CC% -DRTRT_RMDLL
set ATL_SHARED_TDP=TP.lib
set LD=%ATLTGT%\cmd\attolcc %OPTIONS% -verbose -force_tdp_cc -- %LD%
rem make the TP.dll

rem compil the dll sources and the TP thanks to -force_tdp_cc
%CC% -DRTRT_UNLOADABLE -DRTRT_RMDLL -c mydll.cpp
%CC% -DRTRT_UNLOADABLE -DRTRT_RMDLL -c mydll2.cpp

rem generate the TPdll.dll
del tp.obj
cl -c -DRTRT_RMDLL -I. "%ATLTGT%\lib\tpdll.cpp"
link /INCREMENTAL:NO /dll /debug /machine:I386 /out:"TP.dll" /implib:"TP.lib" TPdll.obj


rem generate the dll
%LD% /dll /machine:I386 /out:"mydll.dll"  mydll.obj
%LD% /dll /machine:I386 /out:"mydll2.dll" mydll2.obj

rem compil the main application
%CC% -c example.c

rem link the main app with its dll
%LD% example.obj

rem run app with instrumentation
example.exe

atlsplit atlout.spt
rem studio *.fdc *.tsf *.tpf *.tqf *.tdf *.tio
------------------------------------------------------------------------

3) TestRT GUI이용시 예제
TestMyLib->Settings->Build->Target Deployment Port->TDP output format : Dynamic Libary

2012년 1월 9일 월요일

openSUSE - vmware-config-tools.pl 요구사항



1. Become root
2. Install gcc, kernel-source, kernel-syms, make, binutils
# yast2 --install gcc kernel-source kernel-syms make binutils
3. cd /usr/src/linux
4. make cloneconfig
5. make modules_prepare

That should generate the kernel-headers that /usr/bin/vmware-config-tools.pl requires.

Purify - 기본 사용법

출처 : http://www.ibm.com/developerworks/rational/library/06/0822_satish-giridhar/


Purify는 프로그램 실행 분석을 통해 프로그램에서 발생하는 메모리 에러를 탐지합니다. 프로그램의 적절한 위치에 추가코드를 삽입한 후 해당 프로그램의 실행을 통해 메모리에 대한 데이터 수집 및 검증을 수행합니다. 메모리 체크 실패시 해당 에러를 보고를 하며, 프로그램 종료시점에 메모리 누수 블럭에 대한 스캔을 수행합니다(물론 중간에 누수 스캔 요청을 할 수 있습니다).


Purify는 프로그램과 라이브러리 오브젝트 코드에 삽입을 합니다. 이 과정을 오브젝트 코드 삽입 object code instrumentation (OCI)이라 합니다. Purify는 오브젝트 코드에 삽입을 하며, 소스코드에 삽입하는 것이 아님을 알아두시기 바랍니다. 때문에 소스코드가 없는 써드파티 라이브러리에 대한 메모리 체크가 가능합니다.


여러분의 코드를 디버그 옵션으로 컴파일한다면, Purify는 디버그 정보를 활용하여 에러를 소스라인과 연계할 수 있으며, 에러 보고시에 관련 코드를 보여줄 수 있습니다. 디버그 정보를 포함하지 않는 부분에는, 에러를 오브젝트 코드 정보, 예를 들어 프로그램 카운터(PC), 명령어 등과 에러를 연계할 수 있습니다.


Purify는 메모리 사용 에러와 함께 함수 콜 체인 정보를 보고합니다. 써드파티 라이브러리에서 에러가 발생한 경우에도, 여러분의 소스코드로 부터 라이브러리에 있는 함수를 호출할겁니다. 그러므로 콜 체인에서 소스있는 디버그 정보를 통해 여러분의 코드 어느부분에서 해당 라이브러리 함수를 호출했는 지 파악할 수 있습니다. 이는 에러가 발생한 경우에 대한 귀중한 단서를 제공합니다. 이러한 정보로 부터, 에러가 여러분의 코드에서 발생한 것인지(예를 들어, 초기화하지 않은 인자를 라이브러리에 넘긴 경우) 아니면 써드파티 라이브러리에서 발생한 것인지(예를 들어 라이브러리에 초기화하지 않은 변수가 있는 경우)를 분석할 수 있습니다.


Purify는 다음 단계들과 관련있습니다:
  1. 디버그 옵션으로 여러분의 코드를 컴파일합니다 
  2. Purify를 이용해 바이너리에 오브젝트 코드를 삽입합니다 
  3. 삽입처리된 프로그램을 실행합니다 
  4. Purify가 보고한 에러를 조사하고 수정합니다 


삽입처리 과정은 윈도우즈와 유닉스 플랫폼 간 차이점이 있습니다. 플랫폼별 Purify에 대한 사용방법은 아래 내용을 참고합니다.



윈도우즈 플랫폼에서의 Purify 사용방법


윈도우즈 플랫폼에서, Purify를 사용하는 방법은 두가지 방법이 있습니다:
  • 첫번째 방법: Purify를 Microsoft® Visual Studio® IDE에 통합 설치를 하고, Purify 연계 또는 비연계를 버튼으로 지정할 수 있습니다. Purify를 연계한 경우, 프로젝트 빌드를 하면, Purify는 자동으로 빌드하는 실행파일에 삽입처리를 합니다. 해당 프로그램을 실행하면, Purify의 에러체크 코드가 실행되고 IDE에 에러를 메모리사용 통계와 함께 보고합니다. 
  • 두번째 방법: Purify GUI를 사용하여 프로그램 삽입처리 및 다양한 삽입처리 옵션 설정을 합니다. 삽입처리된 프로그램을 실행하면, Purify GUI 내 윈도우에 에러를 표시합니다. 아래에서는 프로그램 삽입처리, 삽입처리된 프로그램 실행, 보고된 에러조사 등의 단계에 대해 기술합니다. 


Purify는 "정밀" 에러체크를 위해서 Visual Studio의 디폴트 설정에서 만들지 않는 재배치 정보를 필요로 합니다. /fixed:no/incremental:no 등의 링커 옵션을 사용하면 재배치 정보를 추가할 수 있습니다. 재배치 정보가 없는 경우, Purify는 "최소" 에러체크를 시행합니다.


프로그램에 대한 삽입처리 및 실행을 하기 위해, 먼저 Purify를 띄우고 아래 단계를 따릅니다:
  1. memerrors.c 파일 (Download 참조)을 디버그옵션을 이용해 컴파일하고 실행 프로그램을 생성합니다. 
  2. File > Run을 선택하여 Run Program 대화상자 (Figure 1) 를 띄웁니다. 
  3. Program name 상자에 실행 파일 경로를 지정합니다. 
  4. Collect 옵션에서 Error and leak data 선택 버튼을 클릭합니다. 
  5. 프로그램 실행 후에도 콘솔을 유지하기 위해 Pause console after exit 체크 박스를 선택합니다. 
  6. (옵션) Settings를 클릭하여 Purify 설정을 변경합니다. 
  7. Run을 클릭합니다. 


Figure 1. Run Program dialog to instrument an executable program




Purify는 바이너리 파일을 삽입처리하고 프로그램을 실행합니다. Figure 2와 같이 프로그램 및 관련 라이브러리들에 대한 삽입처리 과정을 보여줍니다.

Figure 2. Instrumentation Progress of the executable and DLLs



삽입처리가 끝나면, 프로그램을 실행됩니다. 실행 중, Purify는 탐지한 메모리 엑세스 에러를 보고합니다. 말미에, Purify는 메모리 누수에 대한 보고를 합니다. Figure 3에서 처럼 Purify 에러와 누수 보고서를 보여줍니다.


Figure 3. Memory errors found by Purify (on Windows)



Purify는 에러, 경고, 메모리 누수에 대한 요약 등을 보고합니다. 에러를 클릭하면, 통계, 스택 추적, 라인 번호 등 자세한 정보를 알수있습니다. 예를 들어, array bounds read (ABR) 에러를 클릭하면, 에러 위치와 메모리 할당 위치를 볼수 있습니다(Figure 4). 에러 위치의 소스코드를 보면, ABR 에러가 memerrors.c 파일의 100번째 라인 즉, 스트링 str이 printf 함수로 전달되는 라인에서 발생했습니다. printf 함수는 스트링 str을 NULL바이트를 만날때까지 처리합니다. 여기서는 printf 함수 호출 전에, name으로 부터 10바이트를 str로 복사를 했고, str[11]에 NULL을 설정하여 스트링을 끝처리 했습니다. 그래서 printf는 필시 11 바이트를 읽게 되었습니다. 메모리 할당 위치를 보면, memerrors.c 파일의 107 라인에서 str은 10개의 문자를 갖도록 할당되었습니다. 이를 종합해 보면, str[11]은 배열의 범위 밖을 엑세스하게 되어, array bounds read (ABR) 에러가 발생한 것입니다. 이는 NULL 문자열 끝처리와 배열의 크기에 관련된 오해에서 비롯된 전형적인 에러입니다.


Figure 4. Details of ABR error including source code and line number information (on Windows)



Purify가 보고한 각각의 에러를 조사합니다. Purify가 제공한 상세한 정보의 도움을 받아, 에러에 대한 디버그와 수정작업을 합니다. 결함 수정 후에는 다시 Purify를 실행하여 에러가 없다는 것을 검증합니다.


Purify는 다양한 맞춤 설정 옵션을 통해서 여러분의 요구에 맞는 분석 유형에 탄력적으로 대응합니다. 여러분이 수정할 수 없는 써드파티 라이브러리에서 발생하는 에러를 보고에서 억제하는 방법 또한 제공합니다.


아래 단계는 윈도우즈 플랫폼에서 UMC 에러, 그와 관련된 스택 변수를 명시하기 위한 단계를 제시합니다:
  1. Run Program 대화상자(Figure 1)에서 Settings를 클릭합니다. 
  2. Errors and Leaks 탭에서 Show UMC messages (Figure 5)를 체크합니다. 
  3. Files 탭에서 Additional options 박스 (Figure 6)에 -stack-load-checking을 입력하여, Purify가 스택변수에 UMR 에러를 체크하도록 합니다. 
  4. OK를 클릭하고 Run을 클릭합니다. 
  5. Purify가 실행하면 UMC 메모리 사용 에러를 보고합니다(Figure 3). 


Figure 5. Tick the Checkbox "Show UMC messages" in the Settings dialog (on Windows)



Figure 6. Additional options to check UMR errors on stack variables (on Windows)



여러분은 필터를 정의하여 관심없는 에러 보고를 억제할 수 있습니다. Purify 좌측 영역에서, Run을 우클릭하고 Filter Manager 대화상자를 선택합니다 (Figure 7). Purify는 특정 에러 유형, 특정 콜 스택상의 또는 특정 라이브러리의 에러에 대한 억제할 수 있는 기능을 제공합니다.


Figure 7. Invoking Filter Manager to suppress uninteresting errors (on Windows)



Purify 기능에 관련된 자세한 내용은 Help 메뉴을 참고합니다.


유닉스/리눅스 플랫폼에서의 Purify 사용방법


UNIX 플랫폼상에서는 프로그램을 삽입처리하는 다양한 방법이 있습니다. 가장 간단한 방법은 프로그램 빌드하는 커맨드라인에 purify를 접두어로 추가하는 방법입니다.


예를 들어, 아래와 같이 memerrors.c (Download 참조)파일을 빌드하여 a.out를 생성합니다:
ksh% cc -g memerrors.c


여기에 purify를 접두어로 추가시키면, 삽입처리된 a.out을 빌드합니다:
ksh% purify cc -g memerrors.c


만약 Makefile를 이용해 프로그램을 빌드한다면, 삽입처리용 빌드타겟을 추가할 수 있습니다:
a.out: foo.c bar.c
    $(CC) $(FLAGS) -o $@ $?
a.out.pure: foo.c bar.c
    purify $(CC) $(FLAGS) -o $@ $?



빌드 타켓을 복사하는 경우 아래 두가지 변경만이 필요합니다 (위의 a.out의 경우):
  • 빌드 타겟 이름을 변경합니다 (a.out.pure). 
  • 빌드 타켓 커맨드에 purify를 접두어로 추가합니다. 

삽입처리는 모든 플랫폼에서 링크시에 실행됩니다. AIX에서는, 실행파일에 바로 삽입처리를 적용할 수 있습니다:
ksh% purify a.out

아래는 AIX에서 memerrors.c 파일을 컴파일, 삽입처리, 실행시 로그를 보여줍니다:
ksh % cc -g memerrors.c
ksh % purify a.out
Purify 7.0 AIX (32-bit) (C) Copyright IBM Corporation. 1992, 2006 All Rights Reserved.  
Instrumenting: a.out. libc.a,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,.......,,,,, libcrypt.a., 
Instrumented a.out is a.out.pure.
Done.
ksh % ./a.out.pure



삽입처리된 프로그램을 실행하면 Purify GUI는 메모리 에러를 탐지하면 바로 나타냅니다(Figure 8).


Figure 8. Memory errors found by Purify (on UNIX)



에러를 클릭하면 자세한 정보를 얻을 수 있습니다. Figure 9는 ABR 에러에 대한 자세한 정보를 보여줍니다. 이 정보로 부터 memerrors.c의 107번째 라인에서 NULL 처리된 str 메모리를 할당받았다는 것을 알수 있습니다. 하지만 genABRandABW에서 잘못 계산한 까닭에, name 스트림을 str로 복사한 후에, NULL 바이트가 str[11]에 저장되었습니다. 이로 인해 printf가 str의 범위 밖을 읽게되어 array bounds read (ABR) 에러가 110번째 라인에서 발생했습니다.


Figure 9. Details of ABR errors, including source code and line number information (on UNIX)



유닉스 및 리눅스 시스템상에서 Purify는 모든 UMC 에러와 관련된 스택변수를 추적합니다. 디폴트로 해당 에러는 억제되어 있습니다. 억제된 에러를 보려면 View > Suppressed messages (Figure 10)를 선택합니다.


Figure 10. Seeing suppressed errors (on UNIX)



관심없는 에러 보고를 억제하는 방법은 간단합니다. 에러유형을 선택하고 우클릭후 Suppress 메뉴를 선택합니다(Figure 11).

Figure 11. Suppressing an error (on UNIX)



Purify 기능에 대한 자세한 정는 Help 메뉴를 사용합니다.