검색결과 리스트
(C)ode에 해당되는 글 9건
- 2016.11.30 윈도우 시스템에서 32bit, 64bit 프로세스당 사용 가능 최대 메모리
- 2013.01.17 C에서 기본적으로 열리는 fd
- 2010.10.27 리눅스에서 파일식별자(fd) 갯수 늘리는 방법
- 2010.07.21 일반 계정에서 root권한인 실행파일의 core dump 생성 방법
- 2009.12.15 'Segmentation Fault' 발생 시 시그널(SIGSEGV) 처리 후 core dump 생성하기 2
- 2008.12.01 멀티 스레딩: 스레드 실행 제어 1
- 2008.11.27 adb 사용법
- 2008.11.18 Shell Scriptor, ftp, crontab를 이용한 파일 전송 관리.
- 2008.11.10 C Function Coding시 이렇게 하면 좋다(?)...
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
갑자기 프로세스당 최대 할당 메모리가 궁금해서 조사를 해봤다.
일단,
32bit 윈도우 시스템은 인식가능 메모리가 4GB 이며,
64bit 윈도우 시스템은 인식가능 메모리가 8GB~2TB(윈도우 버전에 따라 다름) 이다.
현제 윈도우10은
최고 Enterprise가 2TB이며, 최소 Home이 128GB이다.
윈도우8은 최고 512GB, 최소 128GB
윈도우7은 최고 192GB, 최소 8GB
왜냐하면?
32bit 주소는 4 Bytes로 최대 메모리 주소 번지가 0xFFFFFFFF이며 2^32로 4GB 이다.
넘어가는 곳의 메모리 주소는 표현 불가능하다.
64bit 주소는 8 Bytes 이므로 최대 메모리 주소번지가 0xFFFFFFFF FFFFFFFF이며 2^64로 16EB(엑사바이트, 페타 다음 단위임)이다.
그러나 16EB까지 인식하는 OS는 없다.
여기까지가 윈도우 시스템(OS)에서 인식하는 메모리 양이면,
이제 주제인 프로세스당 최대 할당 메모리에 대해서 이야기 하겠다.
- 32bit 윈도우 시스템에서 사용하는 주소 할당 내역
0x00000000 ~ 0x0000FFFF : Null 포인터 할당 파티션으로 사용하지 않는다.
0x00010000 ~ 0x7FFEFFFF : 유저 모드 파티션
0x7FFF0000 ~ 0x7FFFFFFF : 64KB 접근 금지 파티션
0x80000000 ~ 0xFFFFFFFF : 커널 모드 파티션
여기사 사용자가 사용하는 프로세스에서 할당해서 사용하는 메모리 영역은 유저 모드 파티션이며 값은 아래와 같다.
2GB - 64KB(Null) - 64KB(접근 금지 파티션) = 2,147,352,576(0x7FFE0000)
약 2GB정도이다.
주소 공간 분할은 윈도우 커널버전에 따라 다르다고 하며, 2GB이상 사용을 위해서 비쥬얼 스튜디오에서 'Enable Large Address' 설정으로 3GB까지 사용이 가능 하다고는 하니, 참고 하면 될 듯하다.
64bit 윈도우 시스템에서 사용하는 주소 할당 내역 자료는 못찾았지만, 아래 페이지에 보면 인식가능 물리 메모리보다는 크게 잡혀 있는 것 같다. 그러므로 신경 쓰지 않아도 되는것으로 보인다.
- https://msdn.microsoft.com/ko-kr/library/windows/desktop/aa366778(v=vs.85).aspx
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
C에서 기본적으로 열리는 FD 값
0 : 키보드 입력
1 : 모니터 (buffer) - fprintf와 같이 버퍼를 사용하여 출력하는 부분
2 : 모니터 (error) - 버퍼를 사용하지않는 에러와 같은 것을 출력하는 부분
출처 : http://blog.naver.com/ackhan?Redirect=Log&logNo=120152097188
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
[FD 갯수 튜닝 방법]
기본 1024 –> 65536
/etc/profile
ulimit -n 65536
/etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
/etc/sysctl.conf
fs.file-max = 65536
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
가끔 일반 계정에서 root 권한이 필요한 바이너리를 실행 하기 위해
권한 설정을 6755와 같이 일반 설정 앞에 6을 붙여서 설정한다.
이러한 경우에 실행되어지는 바이너리가 Segmantation Fault가 발생하더라도
Core dump 파일이 생성 안되는 경우가 있다.
왜냐하면 실행 계정이 일반계정인데 실행 바이너리 권한이 root 이므로
core dump 파일을 생성 시키지 못한다.
이런 경우에 아래의 설정을 확인하여 수정하자.
Solaris --------------------------------------------------------------------------------
coreadm 이용
- 자세한 사용법은 메뉴얼을 찾아보자. 많이 돌아 다님
-------------------------------------------------------------------------------------------
Linux(RedHat Enterprise) ------------------------------------------------------
sysclt.conf 수정
- /etc/sysctl.conf파일내에 아래 라인 추가
fs.suid_dumpable = 2
[버전별 설정방법]
fs.suid_dumpable = 2 # RHEL 5 only
kernel.suid_dumpable = 2 # RHEL 4 only
kernel.core_setuid_ok = 1 # RHEL 3 only
kernel.suid_dumpable = 2 # RHEL 4 only
kernel.core_setuid_ok = 1 # RHEL 3 only
- 적용
sysctl -p로 바로 적용
-------------------------------------------------------------------------------------------
계정의 coredumpsize는 0 이상으로 되어 있어야 core dump가 생성됨
- coredumpsize 수정 방법 [csh SHELL경우]
.cshrc에 'unlimit coredumpsize' 추가
또는 prompt상에서 'limit [coredumpsize] unlimited'라고 명령을 입력하여 실행
-'limit' 로 설정확인
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
C 코딩을 하다보면,
메모리 접근 실수 등으로 'Segmentation Fault'가 자주 발생한다.
이 때, 보통 커널에서 임의로 core dump 생성을 막아 놓지 않았다면,
보통은 디버깅을 하게 된다.
(core dump가 발생하여도 컴파일시에 '-g' 옵션을 주지 않았다면 디버깅은 힘들어진다.)
그러나 'Segmentation Fault'가 발생 할 때, 임의로 시그널을 잡아서
프로그래밍을 하기도 하는데, 이럴 때는 core dump가 생성 되지 않으므로,
임의로 생성을 시켜줘야 한다.
아래는 그 예제이다.
-------------------------------------------------------------------------------------
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
void sighandler(int signum)
{
printf("Process %d got signal %d\n", getpid(), signum); // Segmentation Fault 발생 시 처리 할 문구
signal(signum, SIG_DFL); // 발생한 시그널의 handler를 Default handler로 변경
kill(getpid(), signum); // 발생한 시그널을 다시 발생 시킴
}
void main()
{
int *p = (int*)112233; // 임의의 메모리 번지
int x;
signal(SIGSEGV, sighandler); // SIGSEGV 시그널에 sighandler 등록
x = *p; // 잘못 된 메모리 접근으로 SIGSEGV 발생
printf("got to here...");
}
-------------------------------------------------------------------------------------
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
*** 스레드 실행 제어
*스레드 생성시..
*pThread=AfxBeginThread(pfnThreadProc,pParam,nPriority,nStackSize,dwCreateFlags, lpSecurityAttrs);
dwCreateFlags = 0; // 스레드 생성시 바로 시작
dwCreateFlags = CREATE_SUSPENDED; //스레드가 멈춰진 상태에서 실행
pThread->SuspendThread(); // 스레드 동작 stop
pThread->ResumeThread(); // 스레드 다시 실행
*스레드 쉬게 하기
Sleep(1000); //1초동안 스레드의 CPU 점유 X
Sleep(0); //우선순위가 높거나 같은 스레드에게 CPU 사용권이 넘어감.
CPU를 과다하게 사용할 우려가 있는 루틴에 사용하여 다른 스레드도 CPU를 쓸 수 있도록 하기 위함
*스레드 종료
[ 방법1] 주 프로세스에서 TermivateThread 호출
--> 주 프로세스에서 스레드를 강제로 종료시키면 스레드는 자신이 사용했던 메모리를 해제하는 일 등의 정리 작업을 할 기회 없이 갑자기 죽어버릴 수 있음
[방법2] 외부에서 플래그만 설정하여 스레드에게 종료되어야 한다는 사실을 알리면 스레드가 알아서 종료
*스레드 생성시..
*pThread=AfxBeginThread(pfnThreadProc,pParam,nPriority,nStackSize,dwCreateFlags, lpSecurityAttrs);
dwCreateFlags = 0; // 스레드 생성시 바로 시작
dwCreateFlags = CREATE_SUSPENDED; //스레드가 멈춰진 상태에서 실행
pThread->SuspendThread(); // 스레드 동작 stop
pThread->ResumeThread(); // 스레드 다시 실행
*스레드 쉬게 하기
Sleep(1000); //1초동안 스레드의 CPU 점유 X
Sleep(0); //우선순위가 높거나 같은 스레드에게 CPU 사용권이 넘어감.
CPU를 과다하게 사용할 우려가 있는 루틴에 사용하여 다른 스레드도 CPU를 쓸 수 있도록 하기 위함
*스레드 종료
[ 방법1] 주 프로세스에서 TermivateThread 호출
--> 주 프로세스에서 스레드를 강제로 종료시키면 스레드는 자신이 사용했던 메모리를 해제하는 일 등의 정리 작업을 할 기회 없이 갑자기 죽어버릴 수 있음
[방법2] 외부에서 플래그만 설정하여 스레드에게 종료되어야 한다는 사실을 알리면 스레드가 알아서 종료
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
UNIX "adb" command 는 가장 오래되고 가장 쉽게 얻을 수 있는 UNIX debuggers 이다.
비록 adb 가 GUI 와 같은 특성을 갖지 못하고 source code 에 직접적인 작업을 하지
못하더라도 아주 간단하며 UNIX gurus사이에서 kernel debugger 로 받아들여 진다.
adb 는 kernel crashes 의 시험에만 제한되지 않으며 user program과 application
packages 의 문제를 찾는데도 유효한 tool이다.
'adb(absolute debugger)'라는 이름은 adb가 global symbols와 보통 hexadecimal
인 absolute address를 다루는 사실에서 지어졌다.
adb는 source files,line numbers,local variables,internal function label을 알지
못하며 assembly language와 복잡하지 않은 C code에서 최적으로 작업한다.
adb 는 단순히 이해한다면 하나 또는 두 문자 명령어로서 live system상의 process의
실행을 제어하고 adb의 동작을 제어하며 file이나 memory의 내용을 여러가지 다른
숫자(numerous)형식으로 display한다.
adb는 system crashes 에 의해 만들어진 postmortem file과 live kernel의 작업에
알맞다.
adb는 간단하고 단순한 본성이 있는 반면 adb macor라는 강력한 기능을 제공한다.
= The kernel resident absolute debugger,kadb
kadb 의 특징은 UNIX kernel 대신 booting 할 수 있으며 kernel absolute debugger
이다.
kadb로 boot up 된 후 kernel을 load하고 실행 시킬 수 있다.
그리고 살아 있는 상태에서 kernel을 수정하고 test할 수 있으며 breakpoints의
setting을 가능하게 해 준다.(주-breakpoint란 프로그램이 실행이 중단되어 시스템의
상태,변수들의 값 또는 기억장소의 내용등과 같이 프로그램의 현재상태를 알아볼 수
있는 지점,이러한 중단점은 프로그램의 내용을 debugging 하기위해 사용)
kadb도 macro facility를 가지고 있으나 adb macro 특성과 다르다. kadb에 유효한
macro는 kadb가 실행 가능하도록 새로 만들어져야 한다.
system 이 kadb 로 떨어지면, 다시말해 kadb prompt를 보게되면 모든것이 stop된다.
더이상 윈도우를 사용할 수 있으며 background process를 수행 할 수없으며,console
에서 kadb를 수행하고 있는 사람외엔 system에 access할 수 없다.
= adb hardware & software requirements
adb를 사용하여 savecore files를 분석하기위해 savecore files를 같은 kernel arch.
와 같은 operating system release를 가진 system으로 옮기는 것이 최선이고 가장
간단한 방법이다. 물론 crashed된 시스템 자체에서도 system이 backup되고 running
한다는 것을 가정하에 분석이 가능하다. (note- libraries,programs,directory 등의
조작을 통해 다른 kernel arch와 OS로부터 postmortem files의 분석이가능하다.)
system의 kernel architecture와 OS는 /usr/ucb/arch -k 또는 uname -a command로
알아볼 수 있다.
= Architecture & OS mismatched: Some adb error messages
서로다른 kernel architecture 또는 OS로부터 kernel의 crash dump상에 adb를 시도
하면 아래와 같은 여러가지 error messages를 보게된다.
"Cannot adb -k: vmunix.0 : not a kernel namelist"
SUN4/400 OS4.1.3 의 crash dump file을 SS20,solaris2.3에서 adb를 실행
"Cannot adb -k:unix.0: can't find swapinfo"
SUN4d system의 crash dump file을 SS20,solaris2.3에서 adb를 실행
"Segmentation Fault - core dumped"
SC2000,Solaris2.2 의 crash dump file을 SS20,solaris2.3에서 adb를 실행
"Cannot adb -k: vmcore.0: uncondense error on kvtopdata : Error 0"
"Cannot adb -k: vmcore.0: unable to read kvtopdata"
SUN4m,2.3 system의 crash dump file을 SUN4m,2.2에서 adb를 실행
"Cannot adb -k: cannot mmap vmcore.0's bitmap: Invalid argument"
sun4d 2.3 crash를 sun4 4.1.3에서 adb를 실행
마지막으로 kernel arch와 OS가 잘 match된 경우가 아래에 있다.
____________________________________________________________
howtosolaris# adb -k unix9 vmcore.9
physmem fd87
____________________________________________________________
위 성공적인 예에서 보듯 adb는 memory의 pages 의 숫자를 display 한 후
우리의 첫번째 command를 기다린다.
= The distribution of adb
adb program은 solaris 1.x systems 의 debugging group의 일부분에 속해있다.
Solaris 2 systems에서는 adb는 보다 module화 되어 4개의 packages 에 분산
되어 있다.(man page는 제외)
@ SUNWcar : kadb found
@ SUNWkvm : adb & adb macros
@ SUNWtoo : adb 가 /usr/bin에 link되며 savecore와 strings program을 포함
@ SUNWesu : adbgen utility 를 포함 adbgen 은 프로그래머가 adb macros를
만들 수 있게 도와주는 utility이다.
= The different uses of adb & kadb
core 를 dump시킨 user program을 살펴 보거나 crash가 발생한 postmortem
file을 시험하기 위해서 adb를 사용하려면 object file과 core file을 함께
사용하여야 한다.
- The object file
실행 가능한 object file은 program이나 kernel이 될 수 있는데 이 file은
symbol table과 실행가능한 code를 담고 있다.symbol table은 필요하지는
않지만 그것이 없으면 adb의 symbolic 특성을 사용할 수 없다.
default object file은 a.out이다.
symbol table은 adb 또는 다른 debugger가 symbolic name과 real address를
matching 할 수 있게 한다.adb가 전혀 관심이 없더라도 hexadecimal
address 보다 변수나 function들이 이름을 가지는 편이 사림들에게 보다나은
반응을 줄 것이다.
- The core file
kernel이나 program의 postmortem 분석에서 실패가 일어난 순간에
kernel이나 프로그램에 의해 사용된 memory 의 sanpshot을 나타내는
image file이 core file 이며 default는 core이다.
live system 이 보여질때는 core file은 kernel에 의해 현재 사용되는 memory의
반영이다.
만약 어떤 이유로든 object file과 core file 중 하나라도 없는 경우 adb를
일으켰을때 command line 상의 자리에 dash "-"를 명시할 수 있다.
- Using adb on crash dumps
core file은 error의 원인과 위치를 규정하기 위해 실행 file 과 함께 시험될 수
있으며 adb가 assembly code 와 함께 작업하기 때문에 프로그램의 source code가
없더라도 많은 작업을 할 수 있다.
savecore files 은 physical memory 의 전체내용이 아니더라도 보통 모든 kernel
data space를 포함한다.
adb -k flag 는 crash dump savecore files 이나 live system의 분석에 사용된다.
왜냐면 adb는 kernel data space 에 대한 많은 address translation 작업이 많이
필요하기 때문이다.(주- -k flag는 kernel memory mapping을 수행;system crash
dump 또는 /dev/mem,또는 sapfile을 사용할 때 사용)
- Using adb on live systems
adb는 postmortem files만 debugging 되는 것이 아니다.
adb는 보다 나은 performance를 얻기 위해서 running system을 수정하거나 조정할
수 있다.
adb는 또한 system의 behavior를 차기 boot 시에 바꾸기 위해서 klernel을 수정하
는데도 사용할 수 있다.
default로 adb는 object와 core file를 읽거나 볼 수 밖엔 없다.
그러나 adb를 일으킬 때 -w flag를 쓰거나 adb에서 $W command를 쓰면 write할 수
있다.
- The kernel resident absolute debugger,kadb
live system을 debug할 위치에 있다면 kadb를 사용할 수 있다.
kadb는 operating system대신에 debugger로 초기booting하여 kernel의 나머지를
load하거나 start시킬 수 있도록 만들어져 있다.
어떤것이 panic을 일으켰을때 system이 죽는 상황에서 kadb는 system을 접수하고
얼마간 system을 떠날 수 있다. 이 시점이 kadb 가 우리와 함께 일 할 준비가 된
것이다.
kadb의 대화적 특성은 주요한 이점이다.
kadb를 사용하여 kernel의 breakpoint를 설정해서 마치 커다란 user program과 같이
단계적으로 실행시키고 values를 수정하여 test할 수 있다.
adb를 사용하여 postmortem files를 다룰때는 위와같은 level의 interaction은 준비
되지 않는다.
- adb macros & /usr/lib/adb
비록 adb가 매우 제한된 명령어의 sets을 가지고 있지만 macros로 알려진 상당히
강력한 명령어의 combinations 을 가지고있다.
adb macros는 common commands의 set을 만들고 저장하고 invoke할 수 있게하며
다른 macro를 call할 수 있게 design되어 졌고 최소의 노력으로 강력한 분석을
가능케 한다.
많은 수의 macro files가 solaris 1에서 /usr/lib/adb 안에 준비되어 있다.
Solaris 2 system은 /usr/kvm/lib/adb 에서 adb macros를 찾을 수 있다.
대부분의 macros는 SUN에 의해 준비되어 kernel으로부터 통상적으로 필요한 구조를
읽기쉬운 형식으로 print out 하는데 사용된다.
- General startup syntax
-------------------------
| adb objectfile corefile |
-------------------------
- User program debugging
----------------
| adb a.out core |
----------------
-----------------
| adb myprogram - |
-----------------
user program을 시험하기위해 adb를 invoking 할때의 syntax는 위와같다.
만약 core file이 명시되지 않으면, adb는 현재 directory의 core file을
찾는다.
core file대신 "-"(dash)가 명시되면 adb는 object file을 실행하기위해
system memory를 사용한다. 이와같은 사용법은 추후 "Symbol Tables"에서
살펴보자.
executable image 안에 symbol table 이 없으면 adb는 변수 또는 function
들을 이름에 의해 명시할 수 없다.
이경우 error의 위치를 찾기가 극단적으로 어렵다.
만약 stack traceback 또는 memory 의 시험에서 reports가 오직 hexadecimal
로 되어 있으면 object file로 부터 symbol table이 제거된 상태가 아닌지
check 해보아야 한다.
symbol table의 제거는 UNIX strip command로 가능하지만 한번제거된
symbol table은 복구가 불가능 하다.
- Examining system crash dump postmortem files
--------------------------
| adb -k unix.X vmcore.X |
--------------------------
Solaris 1 system 에서는 object file은 vmunix.X 이며 여기기서 X는 savecore
program이 할당한 crash number이다.
Solaris 2 system에서는 object file은 unix.X라 불리며 여기서의 X도 savecore
에 의해 할당된 crash number이다.
- Examining a live system:Solaris 1
--------------------------
| adb -k /vmunix /dev/mem |
--------------------------
여기엔 crash file 이 없으며 object file 은 booting되고 실제적인 실행 kernel
인 /vmunix 이다. core file 인 /dev/mem 은 현재의 physical memory의 내용이다.
/dev directory 에는 두개의 memory file이 있다.
/dev/mem , /dev/kmem 이 그것이며 서로다른 목적으로 adb와 함께 오직 한가지만
쓰인다.
/dev/kmem device file은 현재 running kernel 에 대한 "kernel virtual memory"
로서 kernel space의 virtual address 만 받아들인다.
/dev/mem device file은 actual physical memory에 대응된다.
adb가 physical memory pages의 copy로 부터 만들어진 core file을 찾도록 되어
졌기 때문에 data 를 위치하기 위해서 내부적으로 physical 에서 virtual address
translations를 자동으로 수행한다.그러므로 physical memory에 대응되는 file을
adb 에게 제공해야 한다.
- Examining a live system:Solaris 2
-----------------------------
| adb -k /dev/ksyms /dev/mem |
-----------------------------
Solaris 2 system은 kernel level에서 Solaris 1 system과 매우다르다.
kernel 은 보다 module화 되어 다양한 조각으로 memory로 적재되며 그것이 꼭
같은 directory 같은 file에서 올 필요가 없다.
/kernel/unix 는 Solaris 1 의 /vmunix file과 가장 비슷한 것으로 전과달리
system의 heart또는 "core" 이며 다른 loadable module이나 device에 대한
symbol은 포함하지 않는다.
새로운 pseudo-device /dev/ksyms 는 system에 현재 적재된 모든 module의 symbol
table 에 대응된다.
또한 /dev/ksyms device 가 open 되었을때 적재되지않은 module로 부터 module을
보호한다. 이것은 우리가 analyze 하는 동안 symbol table을 보증해준다.
그러나 module이 요구에 의해 적재된 이후로 우리가 여기저기 뒤지는 가운데 이전에
요구되지 않은 sections 를 disk로부터 가져옴에 따라 kernel은 계속 size가 커질
것이다. 그래서 새로운 symbols이 더해질 것이나 /dev/ksyms 가 open 되어 있는동안
에전것은 사라지지 않을 것이다.
= Security issues
Solaris 1 system에서는 group 2 ( /etc/group file에 kmem group ) 에 추가되어진
nonroot user는 running kernel에 adb를 사용할 수 있으나, Solaris 2 system에선
kernel을 수정하고 검사할 수 있도록 허가된 nonroot user는 없다
비록 adb 가 GUI 와 같은 특성을 갖지 못하고 source code 에 직접적인 작업을 하지
못하더라도 아주 간단하며 UNIX gurus사이에서 kernel debugger 로 받아들여 진다.
adb 는 kernel crashes 의 시험에만 제한되지 않으며 user program과 application
packages 의 문제를 찾는데도 유효한 tool이다.
'adb(absolute debugger)'라는 이름은 adb가 global symbols와 보통 hexadecimal
인 absolute address를 다루는 사실에서 지어졌다.
adb는 source files,line numbers,local variables,internal function label을 알지
못하며 assembly language와 복잡하지 않은 C code에서 최적으로 작업한다.
adb 는 단순히 이해한다면 하나 또는 두 문자 명령어로서 live system상의 process의
실행을 제어하고 adb의 동작을 제어하며 file이나 memory의 내용을 여러가지 다른
숫자(numerous)형식으로 display한다.
adb는 system crashes 에 의해 만들어진 postmortem file과 live kernel의 작업에
알맞다.
adb는 간단하고 단순한 본성이 있는 반면 adb macor라는 강력한 기능을 제공한다.
= The kernel resident absolute debugger,kadb
kadb 의 특징은 UNIX kernel 대신 booting 할 수 있으며 kernel absolute debugger
이다.
kadb로 boot up 된 후 kernel을 load하고 실행 시킬 수 있다.
그리고 살아 있는 상태에서 kernel을 수정하고 test할 수 있으며 breakpoints의
setting을 가능하게 해 준다.(주-breakpoint란 프로그램이 실행이 중단되어 시스템의
상태,변수들의 값 또는 기억장소의 내용등과 같이 프로그램의 현재상태를 알아볼 수
있는 지점,이러한 중단점은 프로그램의 내용을 debugging 하기위해 사용)
kadb도 macro facility를 가지고 있으나 adb macro 특성과 다르다. kadb에 유효한
macro는 kadb가 실행 가능하도록 새로 만들어져야 한다.
system 이 kadb 로 떨어지면, 다시말해 kadb prompt를 보게되면 모든것이 stop된다.
더이상 윈도우를 사용할 수 있으며 background process를 수행 할 수없으며,console
에서 kadb를 수행하고 있는 사람외엔 system에 access할 수 없다.
= adb hardware & software requirements
adb를 사용하여 savecore files를 분석하기위해 savecore files를 같은 kernel arch.
와 같은 operating system release를 가진 system으로 옮기는 것이 최선이고 가장
간단한 방법이다. 물론 crashed된 시스템 자체에서도 system이 backup되고 running
한다는 것을 가정하에 분석이 가능하다. (note- libraries,programs,directory 등의
조작을 통해 다른 kernel arch와 OS로부터 postmortem files의 분석이가능하다.)
system의 kernel architecture와 OS는 /usr/ucb/arch -k 또는 uname -a command로
알아볼 수 있다.
= Architecture & OS mismatched: Some adb error messages
서로다른 kernel architecture 또는 OS로부터 kernel의 crash dump상에 adb를 시도
하면 아래와 같은 여러가지 error messages를 보게된다.
"Cannot adb -k: vmunix.0 : not a kernel namelist"
SUN4/400 OS4.1.3 의 crash dump file을 SS20,solaris2.3에서 adb를 실행
"Cannot adb -k:unix.0: can't find swapinfo"
SUN4d system의 crash dump file을 SS20,solaris2.3에서 adb를 실행
"Segmentation Fault - core dumped"
SC2000,Solaris2.2 의 crash dump file을 SS20,solaris2.3에서 adb를 실행
"Cannot adb -k: vmcore.0: uncondense error on kvtopdata : Error 0"
"Cannot adb -k: vmcore.0: unable to read kvtopdata"
SUN4m,2.3 system의 crash dump file을 SUN4m,2.2에서 adb를 실행
"Cannot adb -k: cannot mmap vmcore.0's bitmap: Invalid argument"
sun4d 2.3 crash를 sun4 4.1.3에서 adb를 실행
마지막으로 kernel arch와 OS가 잘 match된 경우가 아래에 있다.
____________________________________________________________
howtosolaris# adb -k unix9 vmcore.9
physmem fd87
____________________________________________________________
위 성공적인 예에서 보듯 adb는 memory의 pages 의 숫자를 display 한 후
우리의 첫번째 command를 기다린다.
= The distribution of adb
adb program은 solaris 1.x systems 의 debugging group의 일부분에 속해있다.
Solaris 2 systems에서는 adb는 보다 module화 되어 4개의 packages 에 분산
되어 있다.(man page는 제외)
@ SUNWcar : kadb found
@ SUNWkvm : adb & adb macros
@ SUNWtoo : adb 가 /usr/bin에 link되며 savecore와 strings program을 포함
@ SUNWesu : adbgen utility 를 포함 adbgen 은 프로그래머가 adb macros를
만들 수 있게 도와주는 utility이다.
= The different uses of adb & kadb
core 를 dump시킨 user program을 살펴 보거나 crash가 발생한 postmortem
file을 시험하기 위해서 adb를 사용하려면 object file과 core file을 함께
사용하여야 한다.
- The object file
실행 가능한 object file은 program이나 kernel이 될 수 있는데 이 file은
symbol table과 실행가능한 code를 담고 있다.symbol table은 필요하지는
않지만 그것이 없으면 adb의 symbolic 특성을 사용할 수 없다.
default object file은 a.out이다.
symbol table은 adb 또는 다른 debugger가 symbolic name과 real address를
matching 할 수 있게 한다.adb가 전혀 관심이 없더라도 hexadecimal
address 보다 변수나 function들이 이름을 가지는 편이 사림들에게 보다나은
반응을 줄 것이다.
- The core file
kernel이나 program의 postmortem 분석에서 실패가 일어난 순간에
kernel이나 프로그램에 의해 사용된 memory 의 sanpshot을 나타내는
image file이 core file 이며 default는 core이다.
live system 이 보여질때는 core file은 kernel에 의해 현재 사용되는 memory의
반영이다.
만약 어떤 이유로든 object file과 core file 중 하나라도 없는 경우 adb를
일으켰을때 command line 상의 자리에 dash "-"를 명시할 수 있다.
- Using adb on crash dumps
core file은 error의 원인과 위치를 규정하기 위해 실행 file 과 함께 시험될 수
있으며 adb가 assembly code 와 함께 작업하기 때문에 프로그램의 source code가
없더라도 많은 작업을 할 수 있다.
savecore files 은 physical memory 의 전체내용이 아니더라도 보통 모든 kernel
data space를 포함한다.
adb -k flag 는 crash dump savecore files 이나 live system의 분석에 사용된다.
왜냐면 adb는 kernel data space 에 대한 많은 address translation 작업이 많이
필요하기 때문이다.(주- -k flag는 kernel memory mapping을 수행;system crash
dump 또는 /dev/mem,또는 sapfile을 사용할 때 사용)
- Using adb on live systems
adb는 postmortem files만 debugging 되는 것이 아니다.
adb는 보다 나은 performance를 얻기 위해서 running system을 수정하거나 조정할
수 있다.
adb는 또한 system의 behavior를 차기 boot 시에 바꾸기 위해서 klernel을 수정하
는데도 사용할 수 있다.
default로 adb는 object와 core file를 읽거나 볼 수 밖엔 없다.
그러나 adb를 일으킬 때 -w flag를 쓰거나 adb에서 $W command를 쓰면 write할 수
있다.
- The kernel resident absolute debugger,kadb
live system을 debug할 위치에 있다면 kadb를 사용할 수 있다.
kadb는 operating system대신에 debugger로 초기booting하여 kernel의 나머지를
load하거나 start시킬 수 있도록 만들어져 있다.
어떤것이 panic을 일으켰을때 system이 죽는 상황에서 kadb는 system을 접수하고
얼마간 system을 떠날 수 있다. 이 시점이 kadb 가 우리와 함께 일 할 준비가 된
것이다.
kadb의 대화적 특성은 주요한 이점이다.
kadb를 사용하여 kernel의 breakpoint를 설정해서 마치 커다란 user program과 같이
단계적으로 실행시키고 values를 수정하여 test할 수 있다.
adb를 사용하여 postmortem files를 다룰때는 위와같은 level의 interaction은 준비
되지 않는다.
- adb macros & /usr/lib/adb
비록 adb가 매우 제한된 명령어의 sets을 가지고 있지만 macros로 알려진 상당히
강력한 명령어의 combinations 을 가지고있다.
adb macros는 common commands의 set을 만들고 저장하고 invoke할 수 있게하며
다른 macro를 call할 수 있게 design되어 졌고 최소의 노력으로 강력한 분석을
가능케 한다.
많은 수의 macro files가 solaris 1에서 /usr/lib/adb 안에 준비되어 있다.
Solaris 2 system은 /usr/kvm/lib/adb 에서 adb macros를 찾을 수 있다.
대부분의 macros는 SUN에 의해 준비되어 kernel으로부터 통상적으로 필요한 구조를
읽기쉬운 형식으로 print out 하는데 사용된다.
- General startup syntax
-------------------------
| adb objectfile corefile |
-------------------------
- User program debugging
----------------
| adb a.out core |
----------------
-----------------
| adb myprogram - |
-----------------
user program을 시험하기위해 adb를 invoking 할때의 syntax는 위와같다.
만약 core file이 명시되지 않으면, adb는 현재 directory의 core file을
찾는다.
core file대신 "-"(dash)가 명시되면 adb는 object file을 실행하기위해
system memory를 사용한다. 이와같은 사용법은 추후 "Symbol Tables"에서
살펴보자.
executable image 안에 symbol table 이 없으면 adb는 변수 또는 function
들을 이름에 의해 명시할 수 없다.
이경우 error의 위치를 찾기가 극단적으로 어렵다.
만약 stack traceback 또는 memory 의 시험에서 reports가 오직 hexadecimal
로 되어 있으면 object file로 부터 symbol table이 제거된 상태가 아닌지
check 해보아야 한다.
symbol table의 제거는 UNIX strip command로 가능하지만 한번제거된
symbol table은 복구가 불가능 하다.
- Examining system crash dump postmortem files
--------------------------
| adb -k unix.X vmcore.X |
--------------------------
Solaris 1 system 에서는 object file은 vmunix.X 이며 여기기서 X는 savecore
program이 할당한 crash number이다.
Solaris 2 system에서는 object file은 unix.X라 불리며 여기서의 X도 savecore
에 의해 할당된 crash number이다.
- Examining a live system:Solaris 1
--------------------------
| adb -k /vmunix /dev/mem |
--------------------------
여기엔 crash file 이 없으며 object file 은 booting되고 실제적인 실행 kernel
인 /vmunix 이다. core file 인 /dev/mem 은 현재의 physical memory의 내용이다.
/dev directory 에는 두개의 memory file이 있다.
/dev/mem , /dev/kmem 이 그것이며 서로다른 목적으로 adb와 함께 오직 한가지만
쓰인다.
/dev/kmem device file은 현재 running kernel 에 대한 "kernel virtual memory"
로서 kernel space의 virtual address 만 받아들인다.
/dev/mem device file은 actual physical memory에 대응된다.
adb가 physical memory pages의 copy로 부터 만들어진 core file을 찾도록 되어
졌기 때문에 data 를 위치하기 위해서 내부적으로 physical 에서 virtual address
translations를 자동으로 수행한다.그러므로 physical memory에 대응되는 file을
adb 에게 제공해야 한다.
- Examining a live system:Solaris 2
-----------------------------
| adb -k /dev/ksyms /dev/mem |
-----------------------------
Solaris 2 system은 kernel level에서 Solaris 1 system과 매우다르다.
kernel 은 보다 module화 되어 다양한 조각으로 memory로 적재되며 그것이 꼭
같은 directory 같은 file에서 올 필요가 없다.
/kernel/unix 는 Solaris 1 의 /vmunix file과 가장 비슷한 것으로 전과달리
system의 heart또는 "core" 이며 다른 loadable module이나 device에 대한
symbol은 포함하지 않는다.
새로운 pseudo-device /dev/ksyms 는 system에 현재 적재된 모든 module의 symbol
table 에 대응된다.
또한 /dev/ksyms device 가 open 되었을때 적재되지않은 module로 부터 module을
보호한다. 이것은 우리가 analyze 하는 동안 symbol table을 보증해준다.
그러나 module이 요구에 의해 적재된 이후로 우리가 여기저기 뒤지는 가운데 이전에
요구되지 않은 sections 를 disk로부터 가져옴에 따라 kernel은 계속 size가 커질
것이다. 그래서 새로운 symbols이 더해질 것이나 /dev/ksyms 가 open 되어 있는동안
에전것은 사라지지 않을 것이다.
= Security issues
Solaris 1 system에서는 group 2 ( /etc/group file에 kmem group ) 에 추가되어진
nonroot user는 running kernel에 adb를 사용할 수 있으나, Solaris 2 system에선
kernel을 수정하고 검사할 수 있도록 허가된 nonroot user는 없다
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
일을 하다보면,
날짜별, 시간별로 쌓이는 Log들을 특정 서버에
전송 해야 하는 경우가 생긴다.
이것을 일일이 사람이 하기는 무척 짜증이 나는 일이다.
그러다보니 인간이란게 본래 편한것을 찾게 된다고
어떻게 좀 편하게 알아서 하도록 할수 없을까? 고민을 많이 했었다.
그러다 찾은 방법이 Shell Scriptor와 ftp를 적절히 조합하여 이용하면 될 듯하여
시간 내어서 만들어 봤다.
역시 사람은 머리를 서야 몸이 편하다.
예제..
| #!/bin/sh
# MYHOME : 계정 디렉토리
MYHOME=/home/arhemian
# SBIN_DIR : 이 쉘스크립트가 저장된 디렉토리
SBIN_DIR=${MYHOME}/sbin
# LOG_DIR : 전송할 로그파일이 쌓이는 디렉토리
LOG_DIR=${MYHOME}/log/
# ftp_script_file : ftp를 편하기 쓰기 위해 사용할 명령을 저장한 스크립트 파일
ftp_script_file=${SBIN_DIR}/ftpscript.pcl
# USER, PASSWD : ftp로 접속할 시스템의 계정 및 패스워드
USER=arhemian
PASSWD=12345678
# TARGETIP, TARGETDIR : ftp로 접속할 시스템의 IP주소 및 접속후 파일을 전송할 디렉토리
TARGETIP=192.168.1.100
TARGETDIR=log
# CUR_DATE : 전송하는 현제 날짜를 YYYYMMDD 형태로 저장 (20081118)
CUR_DATE=`date +%Y%m%d`
# 기존에 ftp_script_file이 존재하면 삭제
if [ -r $ftp_script_file ]
then
rm -rf $ftp_script_file
fi
# ftp_script_file을 생성
# ftp_script_file의 내용은 ftp접속후 계정 패스워드를 입력 후
# 타겟 디렉토리에 오늘 날짜로 디렉토리를 생성 후 그곳에
# LOG파일을 전송하도록 되어 있음
cat > $ftp_script_file << FTPSCRIPT_EOF
user ${USER} ${PASSWD}
lcd ${LOG_DIR}
bin
prompt
cd ${TARGETDIR}
mkdir ${CUR_DATE}
cd ${CUR_DATE}
mput *.log
bye
FTPSCRIPT_EOF
# FTP 접속 및 전송
echo "target system : ${USER}, ${TARGETIP}"
ftp -n ${TARGETIP} < ${ftp_script_file}
# 생성된 ftp_script_file 삭제
rm -rf $ftp_script_file
|
위의 예제를 crontab에 등록하여 쓰면 매 일정 시간 마다 알아서 척척척 ㅋㅋ
crontab 사용법은 생략하게다. 다른곳에 자세히 설명된 곳들을 찾아볼것!
사용을 할때는 상황에 맞게 수정을 하면 된다.
이 예제도 쓰고 있는 것에서 중요한 부분만 때어다가 만든거라.....
안맞는 부분이 있을수도 쿨럭!
사실 나는 crontab으로도 쓰지만 간 혹 필요에따라
C코드(데몬프로그램 등)에 추가하여 일정 시간 때마다
scriptor를 동작하도록 쓰고있다.
큰 단점이 있는데 (주의 요망)
타겟의 passwd가 공개가 된다는 점!!!! (C code에서 사용한다면 passwd 같은 경우는
C 코드 내부에서 불러다 쓰면 되므로 문제가 안된다)
뭐 이정도야 몸이 편한것에 대한 대가(?)로 크게 신경 쓸 일은 아니라고 본다.
설정
트랙백
댓글
글
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
벌써 C 코딩만 만 5년이 넘어 가면서...
제 개인 적인 생각을 담아봤습니다.
본래 이 글은 이번에 새로 들어온 신입에게
레포트를 하나 맞겨 봤는데,
이런 저런 충고를 한 내용입니다.
1.될수 있으면 main or task 외에는
function 내에서 큰 size의 값은 선언 하지 않을 것!!(특히 자주 호출 해야 하는 function같은 경우)
- 필요하다면 상위에서 pointer만 받아 오도록 함
2.return 할때, int, short, long, char, void, or pointer만 사용!
- pointer return은 전역 변수의 pointer 또는
상위 function에서 할당해서 넘겨온 인자의 memory size 이내의 값만 사용
- function내부에서 선언된 값의 pointer return은 하면 안됨 (예외, static으로 선언된 값)
3.인자 값으로 인자값들의 유효범위는 function 초기에 항상 체크
- 예를 들면 pointer의 NULL 체크
4.function 내에서 인자 선언 할때 초기값 설정
- 예를 들면 pointer를 선언 할때 NULL로 초기화를 해야,
그 point로 또 다른 function 호출시에 호출된 function에서 잘못된 pointer가 넘어온 것을 체크 할수 있음.
5.가장 중요한것은 function을 만드는 사람이 '갑'이라는 것!!!
- 내부적으로 필요하면 당연히 인터페이스를 바꿔야죠 ^^
- 약간의 고집과 우김이 필요함.
범외, for 또는 if 뒤에 명령 문이 하나 올때 괄호를 빼도 상관이 없지만,
아주 단순한 명령 외에는 붙이는 습관이 좋습니다.
처음 한번에 수정일때는 보기 좋고 깔끔하고 좋은데, 나중에 디버깅을 위해
수정 코드, 추가 코드 또는 프린트등을 넣을 때, 다시 괄호를 넣어야 하는데 실수로 빠트리는 경우가 생겨요 ^^
RECENT COMMENT