vim slow loading

# 언제부터인가 vim 으로 파일 열기가 아주 오래 걸린다.

# 불과 수십MB 정도 파일 오픈이 완료되기까지 수십초가 걸린다.

# 물론 설정된 .vimrc 를 지우면 빠르다.

# 테스트 파일 40MB 정도의 바이너라파일 다운로드

curl -o aws-iam-authenticator https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/darwin/amd64/aws-iam-authenticator

# 파일을 열때 zzz.log 파일에 각 단계별 소요 시간 측정

vim --startuptime zzz.log aws-iam-authenticator

# 측정 결과 파일을 열어 보자.

vi zzz.log 

# 시간은 ms 단위로 각 라인은 다음 2가지 포맷 중 하나로 표시된다.

# clock   self+sourced   self:  sourced script

# clock   elapsed:              other lineskj

... 생략 ...

517.709  001.802  001.361: sourcing /Users/ysoftman/.vim/plugged/lightline.vim/autoload/lightline/colorscheme/one.vim

30908.522  000.736  000.736: sourcing /Users/ysoftman/.vim/plugged/ctrlp.vim/autoload/ctrlp/utils.vim

30920.392  30422.338: BufEnter autocommands

30920.397  000.005: editing files in windows

... 생략 ...

# BufEnter autocommand 단계가 30초가 넘는다(30422.338)

# 이 부분은 파일을 버퍼로 읽은 후 파일 타입에 맞는 셋팅들이 자동으로 실행되는 부분이다.

# 확인해보면 다수의 플러그인이 실행된다.

:autocmd BufEnter

--- Autocommands ---

filetypedetect  BufEnter

    *.xpm     if getline(1) =~ "XPM2" |   setf xpm2 | else |   setf xpm | endif

    *.xpm2    setf xpm2

NERDTree  BufEnter

    NERD_tree_*

              stopinsert

NERDTreeHijackNetrw  BufEnter

    *         call nerdtree#checkForBrowse(expand("<amatch>"))

NERDCommenter  BufEnter

    *         :call s:SetUpForNewFiletype(&filetype, 0)

... 생략 ...

vimball#ShowMesg(0,"Source this file to extract it! (:so %)")|endif

fugitive_status  BufEnter

    index     call s:ReloadWinStatus()

    index.lock

              call s:ReloadWinStatus()

fugitive_merge  BufEnter

    *         if exists('s:rebase_continue') |   exe s:MergeRebase('rebase', 0, '', [getfsize(fugitive#Find('.git/rebase-merge

/git-rebase-todo', s:rebase_continue)) > 0 ? '--continue' : '--abort'], remove(s:, 'rebase_continue')) | endif

Colorizer  BufEnter

    *         silent call colorizer#ColorHighlight(1)

youcompleteme  BufEnter

    *         call s:OnBufferEnter()

              call s:UpdateMatches()

TagbarAutoCmds  BufEnter

    *         if expand('<amatch>') !~ '__Tagbar__.*' |     let s:last_alt_bufnr = bufnr('#') | endif

              call s:AutoUpdate(fnamemodify(expand('<afile>'), ':p'), 0)

# 위에 나온 플러그인들을 .vimrc 에서 주석 처리하며 파일 오픈 해본 결과

# 다음 플러그인을 비활성화(주석처리)하면 빠르다.

# #123 처럼 #로 시작하면 컬러값을 표시해주는 플러그인으로 역시 전체 파일에서 해당 부분을 찾아 처리하는게 느린것 같다.

# 꼭 필요한 기능은 아니니 주석처리 하자.

"Plug 'lilydjwg/colorizer'

최초의 버그는 나방

최초의 버그는 나방(moth)이였다.
1947년 여름 하버드에서 마크2 컴퓨터 연구중인 호퍼가 컴퓨터가 자주 오류를 일으켜 원인을 찾던중 컴퓨터 안에 죽어 눌러 붙은 나방(moth, bug)을 발견하고 제거(de-bug)하니 정상 동작을 했다고 한다. 후에 호퍼는 노트에 나방을 붙여 기록하고 이와 같은 현상을 처리하는것을 debugging 이라고 했다.ㅎ


출처 :
https://en.wikipedia.org/wiki/Grace_Hopper#/media/File:H96566k.jpg

vscode Golang

# vscode Golang 사용하기

# vscode-go extension 설치
# https://marketplace.visualstudio.com/items?itemName=lukehoban.Go
# vscode 업데이트 후 동작하지 않으면 go extension 삭제하고 재설치
ctrl + shift + p -> ext install (install extension) -> "Rich Go language support for Visual Studio Code" 설치 -> Restart

# 사용자 설정(default setting 값은 수정할 수 없고, overwrite 된다.)
File -> Preferences -> User Settings

{

  "go.buildOnSave": true,

  "go.lintOnSave": true,

  "go.vetOnSave": true,

  "go.buildTags": "",

  "go.buildFlags": [],

  "go.lintFlags": [],

  "go.vetFlags": [],

  "go.coverOnSave": false,

  "go.useCodeSnippetsOnFunctionSuggest": false,

  "go.formatOnSave": true,

  // goreturns 은 goimports(자동 임포트), gofmt(자동 포맷팅)를 사용하고 리턴코드도 자동으로 채워준다.

  "go.formatTool": "goreturns",

  "go.gocodeAutoBuild": false,

  // 맥,리눅스 기준

  //"go.goroot": "/usr/local/go",

  //"go.gopath": "/Users/ysoftman/gopath"

  // 윈도우 기준

  "go.goroot": "c:\\go",

  "go.gopath": "c:\\ysoftman\\Project\\gopath"

}

#####

# delve(디버거) 설치(go v1.5 이상 필요)
# https://github.com/derekparker/delve/tree/master/Documentation/installation

# 맥의 경우
brew install go-delve/delve/delve

# 리눅스의 경우
go get -v -u github.com/peterh/liner github.com/derekparker/delve/cmd/dlv
cd $GOPATH/src/github.com/derekparker/delve
make install

# 윈도우 mingw-w64
# http://sourceforge.net/projects/mingw-w64/
# mingw-w64 설치시 아래와 같이 선택
Version: Latest available (5.3.0 at time of writing)
Architecture: x86_64
Threads: posix (shouldn't actually matter)
Exception: seh (shouldn't actually matter)
Build revision: Latest available (0 at time of writing)

# 설치경로 C:\mingw-w64\x86_64-5.3.0-posix-seh-rt_v4-rev0
# 설치 완료 후 환경 변수 PATH 에 경로 추가
# C:\mingw-w64\x86_64-5.3.0-posix-seh-rt_v4-rev0\mingw64\bin
# dlv 라이브러리 빌드 및 설치

# 참고로 다른 버전의 mingw 가 설치되어 path 로 잡혀 있어 실행되면
# 에러가 발생하니 환경변수 path 에서 제외시키던가 다른버전은 삭제하도록 한다.
go get -v -u github.com/peterh/liner github.com/derekparker/delve/cmd/dlv

cd c:\ysoftman\project\gopath\src\github.com\derekparker\delve

set GO15VENDOREXPERIMENT=1
mingw32-make install

# 처음에는 디버거 선택 화면이 나오고 go 선택하면  launch 환경을 편집할 수 있다.
# 설정은 현재 워킹 디렉토리에서 .vscode/launch.json 로 저장된다.

{

  "version": "0.2.0",

  "configurations": [

    {

      "name": "Launch",

      "type": "go",

      "request": "launch",

      "mode": "debug",

      "program": "${workspaceRoot}",

      "env": {},

      "args": []

    }

  ]

}

# go 포맷팅(gofmt)
alt + shift + f

# go back
alt + left arrow

# go forward
alt + right arrow

# debugging start
f5

# debugging stop
shift + f5

# debugging step over
f10

# debugging step into
f11

# debugging step out
Shift+F11

# 기타 Command Palette(ctrl + shift + p) 에서 명령어를 찾아 수행

#####

# 필요시 golang 툴 설치
go get -u -v github.com/nsf/gocode
go get -u -v github.com/rogpeppe/godef
go get -u -v github.com/golang/lint/golint
go get -u -v github.com/lukehoban/go-find-references
go get -u -v github.com/lukehoban/go-outline
go get -u -v sourcegraph.com/sqs/goreturns
go get -u -v golang.org/x/tools/cmd/gorename
go get -u -v github.com/tpng/gopkgs
go get -u -v github.com/newhook/go-symbols

debugging in Visual C++ 2008 Release

Release 모드에서 디버깅하려면 다음과 같이 설정한다.

프로젝트 속성 -> 구성속성 -> C/C++ -> 일반 -> 디버깅 정보 형식 -> 프로그램 데이터베이스(/Zi)
프로젝트 속성 -> 구성속성 -> C/C++ -> 최적화 -> 최적화 -> 사용안함(/Od)
프로젝트 속성 -> 구성속성 -> 링커 -> 디버깅 -> 디버그 정보 생성 -> 예(/DEBUG)

Windows .dmp 분석

# 방법1 - visual studio 이용
디버깅시 소스를 보려면 .exe .pdb .dmp 이 같은 위치에 있도록 한다.
visual studio 에서 프로젝트로 .dmp 열기 -> 디버깅 시작(F5) -> 프로그램이 죽은 시점의 콜스택과 소스를 볼 수 있다.

만약 .pdb 가 있어도 콜스택과 소스코드가 제대로 보이지 않으면 윈도우 기본 심볼 파일을 다운 받고(방법2 참고)
옵션 -> 디버깅 -> 기호 -> 기보파일(.pdb) 위치를 설정한다.(기호로드는 시간이 오래걸리고 진행상태를 알 수 없어 추천하지 않는다.)


위와 같이 설정하고 디버깅 시작하면 제대로된 콜스택과 윈도우 시스템의 소스코드를 볼 수 있다.
콜스택에서 사용자 함수를 클릭하면 해당 소스를 요구하고 이때 소스(.cpp) 경로를 직접 입력하도록 한다.

# 방법2 - windbg 이용
Windbg 는 크래쉬 발생시 생성된 덤프파일(.dmp) 분석을 위해 visual studio 외에 사용할 수 있는 툴이다.
다운로드 http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

File -> Symbol File Path 에 다음과 같이 설정한다.
SRV 는 심볼을 사용하겠다는 뜻
D:\WindowsSymbols 는 심볼 다운 받아 저장할 곳
http://msdl.microsoft.com/download/symbols 는 심볼을 다운로드할 url
d:\ysoftman\ysoftman_application 는 .pdb 파일이 있는 위치
SRV*D:\WindowsSymbols*http://msdl.microsoft.com/download/symbols;d:\ysoftman\ysoftman_application

소스 파일이 있다면 File -> Source File Path 를 주고 call stack 등에서 더블클릭하면 해당 소스가 보이게 된다.

크래시 분석 수행
!analyze -v

쓰레드별 lock 상태 보기
!locks

참고로 critical section 에서의 lock count 은 초기값이 -1 이다.
lock count 는 각각의 쓰레드가 EnterCriticalSection 를 호출할 때마다 증가 되고 LeaveCriticalSection 를 호출할 때마다 감소된다.

lock count 현재 critical section 을 점유한 쓰레드 외에 EnterCriticalSection 를 통해 대기중인 쓰레드 개수를 나타낸다.

그런데 lock count 가 -1 보다 작아질 수 있는 버그가 있어 windows server 2003 sp1 이후에는 lock count 해석하는 방법이 달라졌다

자세한 내용은 http://msdn.microsoft.com/en-us/library/windows/hardware/ff541979(v=vs.85).aspx

Android 자주 사용되는 adb(Android Debug Bridge) 툴의 기능

# Linux 에서 vnc 설치 (root)
yum -y install vnc-server

# vnc 환경 설정 (root)
vi /etc/sysconfig/vncservers

# vnc 포트는 5900이고 +1 한 5901 은 root 가 사용하고 +2 한 5902 는 ysoftman 이 사용하는 식이다
VNCSERVERS="1:root 2:ysoftman"
#1번(root)와 2번(ysoftman) 에대한 옵션 설정
VNCSERVERARGS[1]="-geometry 1024x768"
VNCSERVERARGS[2]="-geometry 1024x768"

# vnc 암호 설정 (root)(ysoftman에서도 똑같이 수행)
# 암호를 설정하면 .vnc 디렉토리에 passwd 라는 암호파일이 생기게 됨
cd ~
vncpasswd

# vnc 서비스 시작하기 (root)
/sbin/service vncserver start

# 부팅시 재시작 설정 (root)
/sbin/chkconfig vncserver on

# vnc 포트 확인 (root)
nmap localhost

# 방화벽 disable (또는 설정에서 vnc 포트 예외처리)
sudo iptables -F


# X-window 로 작동되지 않을때 (root)(ysoftman에서도 똑같이 수행)
# vncserver 서비스를 한번 시작하게 되면 .vnc/xstartup 파일 생성되며 이를 수정한다.
vi ~/.vnc/xstartup

# 다음을 주석 해제
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

# vnc 서비스를 재시작하여 반영 (root)
/sbin/service vncserver restart

# VNC 클라이언트 프로그램 다운로드
http://www.realvnc.com/
http://www.tightvnc.com/
http://www.uvnc.com/

Visual C++ Detected memory leaks debugging

'Detected memory leaks!' 즉 메모리가 누수시 AfxSetAllocStop(number) 이용하면 쉽게 디버깅이 가능하다.

만약 출력창에 다음과 같이 메모리 누수가 나타나면

Dumping objects ->

{1359} normal block at 0x0139D7D8, 332 bytes long.

 Data: <                > 00 00 00 00 CD CD CD CD 00 00 00 00 00 00 00 00 

{1358} normal block at 0x0139D758, 64 bytes long.

 Data: <d:\Project\OCR-N> 64 3A 5C 50 72 6F 6A 65 63 74 5C 4F 43 52 2D 4E 

소스 코드 시작지점(main, init. 생성자....등)에서 {} 안에 있는 숫자를 파라미터로 설정하여 다음과 같이 사용한다.

AfxSetAllocStop(1359);

그리고 나서 F5 로 디버깅을 시작하면 메모리를 공간을 확보하는 시점(new, alloc()...)에 브레이크포인트가 걸린다.

이후 호출스택을 보면 어느시점에서 어떤 녀석이 메모리를 사용하려고 하는지 알수 있다.

결국 그 어떤 녀석이 나중에 메모리 해제가 안되는 것으로 파악되고 코드를 수정하면 된다.

AfxSetAllocStop 는 MFC 환경에서 사용되는 함수이다. 만약 MFC 환경이 아니라면 다음과 같이 _CrtSetBreakAlloc() 를 사용한다.

void main()

{

#if defined(WIN32) || defined(WIN64)

#ifdef _DEBUG

#include <crtdbg.h>

 // _CRTDBG_ALLOC_MEM_DF ==> _CLIENT_BLOCK 에 메모리를 할당에 대해서 덤프

 // _CRTDBG_LEAK_CHECK_DF ==> 프로그램이 종료될 때 자동으로 _CrtDumpMemoryLeaks() 를 호출하여 메모리 누수시 덤프

 _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

 // 해제 안되는 new 의 파일과 라인수를 파악한다.

 #define new new(_NORMAL_BLOCK, __FILE__, __LINE__)

 // 메모리 누수시 블록숫자값(출력창의{1234})을 주면 메모리 공간을 확보하는 시점에 브레이크포인트가 걸린다.

 _CrtSetBreakAlloc(1359);

#endif

#endif

}