jusang blog

tmux tmux는 ssh 개발 시 ssh 접속을 끊어도 개발이 유지될 수 있는 유틸 입니다. 사용 방법 최초 한번은 tmux를 실행 합니다. tmux 원하는 작업을 수행합니다. git clone my.git.com 이후 detach를 합니다. 이 후 ssh 연결을 끊어도 서버가 살아있는 한 작업이 계속됩니다. # detach 명령어 : 'Ctrl + b' -> 'd' 입력 tmux [detached (from session 0)] (2)에서 실행한 작업 상황을 보거나 수정할 때에는 tmux를 attach합니다. tmux attach # tmux attach -t 0  종료 하고 싶을 때에는 'Ctrl + d' 또는 exit 명령어를 수행합니다.

Termux로 openssh 접속하기 안드로이드 Termux를 서버로 두고 openssh를 PC 등에서 접속하는 가이드 입니다. 1. Termux 환경 설치 $ pkg install sshd 2. ID / Password 설정 $ whoami u0_a419 $ passwd # 비밀번호 설정 3. (공유기 접속 시) 포트포워딩 설정 ※ termux의 sshd 포트번호는 22가 아닌 8022 입니다. 4. ssh 접속 mobaxterm, putty, ssh 등으로 접속 2번에서 확인한 ID/Passwd를 사용하여 접속합니다.

gdb thread 분석하기. (gdb) info threads (gdb) thread [num] (gdb) bt https://juwith.blogspot.com/2019/10/linux-useful-tool-gdb.html

버전 정책 관리의 필요성 Autotools 뿐만 아니라 모든 라이브러리는 버전관리가 필수적입니다. 예를들어 내가 만든 라이브러리의 기존에 API가 삭제되었다면, 내가 만든 라이브러리를 사용하는 다른 누군가는 빌드에러가 발생하게 됩니다. 빌드에러가 발생하면 원인을 추적하는데에도 불필요한 시간이 소요되고 API가 삭제되었다면 그 라이브러리를 사용하기 위해서는 나의 소스를 다시 수정해야만 합니다. 따라서 라이브러리를 만들때에는 버전정보를 달아놓고, 기능변동이나 API변동에 따라 적절하게 버전을 수정해야합니다. 그래야만 나의 라이브러리를 사용하는 다른 사용자들이 버전정보를 보고 호환이 될 수 있다, 없다를 판단하여 사용할 수 있기 때문입니다. 버전관리의 기본 정책 버전관리의 기본 정책은 다음과 같습니다. autotools은 version 정보가 'current:revision:age'로 되어있으며, 각 자리가 계산된 뒤에 라이브러리 뒤에 version으로 붙습니다. 릴리즈 전 릴리즈 전에는 내부 개발자간의 개발만 일어나게 됩니다. 따라서 불필요하게 버전이 자주 바뀌면 개발에 불편함이 있습니다. 릴리즈 전에는 아래와 같이 버전정보를 부여합니다. libhello_la_LDFLAGS = \ -version-info 0:0:0 1. 단순 소스가 수정된 경우 current : revision +1 : age 즉 라이브러리 버전으로는 아래와 같습니다. libhello.so.0.0.0 -> 소스 수정 libhello.so.0.0.1 -> 소스 수정 libhello.so.0.0.2 2. Interface(user가 사용하게될 API)가 추가,변경,삭제된 경우 current+1 : 0 : age 즉 라이브러리 버전으로는 아래와 같습니다. libhello.so.0.0.0 -> API 추가,변경,삭제 libhello.so.1.0.0 -> 소스 수정 libhello.so.0.1.1 -> API 추가,변경,삭제 libhell...

cmake pkgconfig pkg_check_modules ( LIBJPEG libjpeg ) cmake lib 추가 target_link_libraries ( mybin ${ LIBJPEG_LIBRARIES } ) cmake include dir 추가 include_directories ( ${ LIBJPEG_INCLUDE_DIRS } ) cmake cflgas 추가 set ( CMAKE_C_FLAGS ${ LIBJPEG_CFLAGS } )

Jenkins에 E-mail 등록하기 메인 페이지에서 Manage Jenkins를 클릭 합니다. Configure System을 클릭 합니다. 맨 아래에 E-mail Notification칸에 'Advanced...'를 클릭하고 email 정보를 적습니다. 'Test configuration by sending test e-mail'을 체크하면 정상적으로 email이 가는 지 확인할 수 있습니다. 이제 이메일 설정이 완료되었습니다. 빌드 페이지에서 E-mail Notification을 설정하면 빌드 실패 시 이메일 알림을 받아볼 수 있습니다.

해당 가이드는 Freestyle project기능으로 간단하게 자동으로 빌드되는 예제에 대한 가이드입니다. 자동 빌드는 시간별, commit별 등 다양하게 수정할 수 있어서 사용자가 매 번 확인을 하지 않더라도 빌드 에러 확인이 용이합니다. 또한 주기적은 형상이 있으므로 런타임 에러 추적이 용이합니다. jenkins는 local뿐 아니라 인트라넷, 인터넷망으로도 활용 가능하므로 공동 작업을 할 때 개발자들이 공동된 형상을 볼 수 있기 때문에 공동 작업시 상당히 유용합니다. 프로젝트 생성 프로젝트 생성을 위해 http://localhost:8080/ 에 접속합니다. New Item을 누른 후 Project 이름을 입력합니다.  * Jenkins 내부적으로 폴더 이름이 되기 때문에 띄어쓰기는 쓰지 않는게 좋습니다. 1. General 오래된 빌드 버리기 등 일반적인 셋팅을 할 수 있습니다. Jenkins plugin에 따라 메뉴가 추가될 수 있습니다. Description에는 프로젝트의 설명을 간단하게 써줍니다. 저는 오래된 빌드를 자동으로 삭제하고 싶기 때문에 Discard old builds를 체크했습니다. 며칠 또는 몇개까지 유지하고 그 이상이 되면 마지막에 빌드된 결과물은 자동으로 삭제가 됩니다. 2. Source Code Management git, svn, repo 등 소스 다운로드 형상을 관리하는 부분입니다. 예를들어 https://github.com/JusangMaeng/simplest-autotools.git 저장소를 다운받아봅시다. 저장소는 git이므로 git에 체크 후 url을 적어줍니다. 특정 branch나 tag도 지정이 가능합니다. 3. Build Triggers 빌드를 할 동작을 구현하는 부분 입니다. git commit이 발생했을 때, 일정 주기 등 다양하게 설정을 할 수 있습니다. 일정 주기로 설정하는 방법을 예로들겠습니다. 형식은 5가지를 지정하게 되어있...

debugging 심볼 기본 위치 ※ 심볼의 위치는 설정에 따라 변경 가능합니다. source : /usr/src/debug/ <SOURCE_PATH> lib : /usr/lib/.debug/ lib<NAME>.so* bin : /usr/bin/.debug/ <BIN> 샘플 코드 실행 방법 1. gdb 실행 후 프로그램 실행 $ gdb ./gdbanalysis (gdb) r arg1 arg2 arg3  : prompt에서 run 가능 실행 방법 2. gdb 실행 시 옵션과 함께 실행 $ gdb -ex=r --args ./gdbanalysis arg1 arg2 arg3 실행 방법 3. running process $ gdb -p PID 또는 $ gdb (gdb) attach * gdb 실행 시 break가 됩니다. '(gdb) c' 명령어로 다시 run이 가능합니다. 분석 시점 1. fault가 발생하는 지점에서 분석 fault가 나는 지점이 발생하면 자동으로 gdb가 멈춥니다. gdb는 fault가 발생한 지점에서 frame 별로 보여줍니다. 위의 소스는 38번째 줄에서 abrot가 발생했습니다.   (gdb) bt #0  0x00000034cd498bf6 in __strcpy_sse2_unaligned () from /lib64/libc.so.6 #1  0x00000000004006eb in main () at hello.c:38 #0, #1은 frame을 표시한 것 입니다. 숫자가 높은 순에서 낮은 순으로 수행이 되었으며 수행될 때의 상태가 frame별로 저장이 된 것 입니다. 분석은 숫자가 가장 높은 최초의 call을 한 함수부터 frame을 내려가면서 분석을 하는 것이 좋습니다. 분석 시점 2. core file 분석 core dump는 fault가 나는 시점에 모든 정보가 담긴 파일입...

vmstat (virtual memory statistics)는 리눅스 프로세서의 메모리, disk, cpu performance 모니터링 도구입니다. ※ 중요 : vmstat의 처음 결과는 부팅 이후 평균수치 입니다. 이후의 결과는 일정 샘플링 기간 동안의 결과 값 입니다. 사용 방법  $ vmstat [options] [delay [count]] 세부 옵션은 아래와 같습니다. Options:   -a, --active            active/inactive memory   -f, --forks             number of forks since boot   -m, --slabs             slabinfo   -n, --one-header        do not redisplay header   -s, --stats             event counter statistics   -d, --disk              disk statistics   -D, --disk-sum          summarize disk statistics   -p, --partit...

Jenkins는 지속적 통합(continuous integration) 서비스를 제공하는 툴 입니다. 즉 CI툴 입니다. 지속적 통합(CI)이란 지속적으로 품질을 컨트롤 할 수 있는 프로세스 입니다. 이 블로그는 linux만을 다루기 때문에 jenkins의 linux 설치방법과 간단한 빌드 설정을 소개할 예정입니다. 1. Jenkins 다운로드 Jenkins는 JVM에서 돌아가므로 JRE(Java Runtime Environment)가 설치될 수 있는 환경이라면 모두 사용 가능합니다. 다운로드 :  https://jenkins.io/download/ 각 운영체제에 맞는 패키지를 받아도 상관없습니다만, java 패키지(jenkins.war)로 받으면 설치가 간단합니다. 2. Jenkins 설치 사실 위에서 jenkins.war 파일을 받은 것만으로 설치가 끝난 것 입니다. 아래 java 명령어로 실행을 할 수 있습니다. $ java -jar jenkins.war 하지만 이렇게 실행한다면 터미널이 꺼지는 순간에 jenkins가 종료 됩니다. 아래와 같이 nohup으로 실행시키면 터미널이 종료되더라도 계속 실행이 됩니다. $ nohup java -jar jenkins.war & 3. Jenkins 셋업 jenkins의 기본 주소는 자기 자신의 IP입니다. 웹 브라우저로 localhost 8080포트( http://localhost:8080/ )로 접속을 하면 아래 jenkins 페이지가 뜹니다. 기본 password는 jenkins 설치 폴더에 'initialAdminPassword'파일로 존재합니다. i.e.) /home/jusang/.jenkins/secrets/initialAdminPassword 로그인 후 'Install suggested plugins'를 눌러줍니다. 참고로 설치 후 필요한 plugins을 추가 설치할 수 있습니다. plugin을...

Autotools는 linux에서 가장 보편적으로 사용하는 빌드 도구 입니다. configure.ac, Makefile.am, configure, Makefile.in, aclocal.m4 와 같은 폴더구조를 많이 보셨을 겁니다. 이런 구조로 만들어진 빌드 도구를 autotools라고 합니다. Autotools는 automake 또는 autoconf와 헷갈릴 수 있는데, Autotools는 Autoconf, Automake, Libtool, Gettext로 구성되는 것을 Autotools라고 부릅니다. Autotools의 최고 장점은 host, target, toolchain에 큰 의존성이 없이 빌드가 가능하다는 점 입니다. 아래와 같은 순서로 Autotools 환경을 구성할 수 있습니다. 1. Makefile.am 2. configure.ac 3. configure 4. make 아래 가이드는 github에 올려두었으니 참고하시기 바랍니다. $ git clone https://github.com/juwith/simplest-autotools.git $ git checkout 380e0d6d43db10cc6de5ec4dbaceb4337d5d2be4 Makefile.am Makefile.am은 Makefile이 생성될 폴더 위치에 모두 생성합니다. 하나의 bin과 하나의 lib를 생성하는 프로젝트를 생성하는 경우를 예를 들어 봅시다. . ├── Makefile.am ├── src │   ├── hello.c │   ├── hello.h │   └── Makefile.am └── test     ├── main.c     └── Makefile.am src에 있는 소스는 동적 라이브러리르 생성할 소스고, test에 있는 소스는 바이너리를 생성할 소스 입니다. Makefile.am에는 빌드...

Valgrind의 memcheck 기능 중 leak의 기능을 살펴보겠습니다. 이 기능은 heap메모리에 메모리 할당,메모리 해제을 분석합니다. memory leak은 실행 시 '--leak-check' 옵션으로 추적할 수 있으며 기본 설정은 summry입니다. * --leak-check=<no|summary|yes|full> [default: summary] 소스 빌드 및 실행  $  cc -o hello hello.c -g3 -O0  $ valgrind ./hello 결과 -bash-4.2$ valgrind ./hello ==31359== Memcheck, a memory error detector ==31359== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==31359== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==31359== Command: ./hello ==31359== leak ==31359== ==31359== HEAP SUMMARY: ==31359==     in use at exit: 10 bytes in 1 blocks ==31359==   total heap usage: 1 allocs, 0 frees, 10 bytes allocated ==31359== ==31359== LEAK SUMMARY: ==31359==     definitely lost: 10 bytes in 1 blocks ==31359==    indirectly lost: 0 bytes in 0 blocks ==31359==      poss...

Memcheck는 메모리 관련 에러를 찾을 수 있는 vlagrind의 기능입니다. 검출 가능한 에러 접근 불가능한 영역에 대한 메모리 접근. 예) heap 영역의 오버런 또는 언더런, stack 영역의 오버런, 메모리 해제 후 사용 접근 정의되지 않은 값. 예) 초기화 되지 않음 힙 영역의 잘못된 메모리 해제. 예) double free, 메모리 할당과 해제의 미스 매칭 memcpy함수의 src / dst가 겹치는 경우 메모리 할당 시 인자로 이상한 값을 전달하는 경우 메모리 누수 위와 같은 에러를 찾을 수 있기 때문에 memcheck를 활용하는 것은 프로그램의 신뢰성을 높일 수 있습니다. 사용자가 오래 사용하여 검증되었다고 생각하는 코드는 메모리 에러를 생각하지 않을 뿐더러 소스 코드로 검출하는 작업도 오래 사용해서 문제가 없을 것이라는 인식 때문에 자세히 보지 않게 됩니다. 특히나 매우 작은 메모리가 지속적으로 누수 되는 것은 코드로 보았을 때 찾기 힘들 뿐더러, 장시간 프로그램을 동작하지 않으면 누수가 나는지 조차도 모를 수 있습니다. valgrind는 이런 작은 부분의 메모리 에러까지 확인할 수 있습니다. 참고 자료 http://valgrind.org/docs/manual/mc-manual.html

Valgrind 는 linux 동적분석 툴 입니다. 별도의 소스 수정 없이 바이너리가 실행된 후에 아래와 같은 분석이 가능합니다. Memcheck : 메모리 에러 검출 (메모리 leak, 잘못된 메모리 사용 등) Cachegrind : 캐시 사용 분석 Callgrind : call 순서를 graph로 분석 Helgrind : 쓰레드 에러 분석 DRD : 쓰레드 에러 분석, Helgrind와 다른 분석 방식을 사용함. Massif : heap 메모리 프로파일 DHAT : heap 메모리 분석 SGcheck : stack, global array 분석 BBV : 블록 벡터 생성기 Valgrind는 정적 분석에서 발견하지 못한 에러를 검출할 수 있는 강력한 툴 입니다. 모든 사용법은 아니더라도 Memcheck는 사용법을 익혀 메모리 에러를 검출하는 것이 프로그램의 신뢰성을 높힐 수 있습니다.