PLT 와 GOT – 리눅스 동적 링킹과 지연 바인딩
공유 라이브러리는 프로세스마다 다른 주소에 올라간다. ASLR이 켜져 있으면 같은 libc.so.6도 실행할 때마다 위치가 바뀐다. 그런데 .text는 읽기 전용으로 매핑되어 여러 프로세스가 물리 페이지를 공유하므로, call printf의 피연산자에 실제 주소를…
리눅스 시스템 디버깅
공유 라이브러리는 프로세스마다 다른 주소에 올라간다. ASLR이 켜져 있으면 같은 libc.so.6도 실행할 때마다 위치가 바뀐다. 그런데 .text는 읽기 전용으로 매핑되어 여러 프로세스가 물리 페이지를 공유하므로, call printf의 피연산자에 실제 주소를…
스핀락(spinlock)과 뮤텍스(mutex)를 잘못 쓴 커널 코드는 대부분 조용히 지나간다. 초기화하지 않은 스핀락은 0으로 채워진 메모리라 x86에서는 그냥 동작하고, 스핀락 안에서 호출한 kmalloc(GFP_KERNEL)은 메모리가 넉넉하면 잠들지 않으니 아무 일도 없다. 그러다…
장애 상황을 재현하려고 보면 소스가 없는 바이너리이거나, 디스크를 실제로 가득 채우거나 시스템 시계를 바꿔야 하는 경우가 많다. 코드를 고치지 않고 "이 프로그램이 어떤 파일을 여는지", "디스크가 꽉 차면 에러 처리를…
슬랩 캐시가 계속 커질 때 /proc/slabinfo는 어느 캐시에 오브젝트가 몇 개 있는지만 알려주고, 그 오브젝트를 누가 할당했는지는 알려주지 않는다. SLUB에는 오브젝트마다 마지막 할당·해제 호출 스택을 기록하는 기능이 있어서 이 질문에…
멀티코어에서 처리량이 코어 수만큼 늘지 않고 어느 지점부터 오히려 떨어질 때, 원인이 락 경합(lock contention)인 경우가 많다. perf lock은 배포판 커널 그대로도 쓸 수 있어 편하지만 트레이스포인트를 기록하는 방식이라 "측정하는…
스레드를 늘렸는데 처리량이 비례해서 오르지 않고, 프로파일을 떠보면 _int_malloc이나 __lll_lock_wait 같은 함수가 상위에 올라오는 경우가 있다. glibc의 malloc은 아레나(arena) 단위로 락을 잡기 때문에, 짧은 객체를 자주 할당·해제하는 코드에서는 이 락이…
스레드를 늘렸는데 처리량이 그대로이거나 오히려 떨어질 때, top은 sys 시간이 높다는 것까지만 알려준다. perf top으로 어느 함수가 CPU를 쓰는지 좁혀도 "락을 기다리느라 잠들어 있던 시간"은 CPU 프로파일에 잡히지 않는다. perf…
프로덕션에서 프로세스가 Segmentation fault로 죽었는데 로그에는 아무것도 안 남았다. 재현도 안 되고, 붙어 있던 디버거도 없다. 이럴 때 유일한 단서가 코어 덤프(core dump)다. 그런데 Ubuntu 24.04를 기본 설정 그대로 쓰면…
CPU 사용률은 낮은데 응답이 느린 서비스를 만나면 perf top이 별 도움이 안 된다. 화면에 뜨는 건 지금 CPU를 쓰고 있는 함수뿐이라, 정작 시간을 잡아먹는 대기 구간은 아무 데도 나오지 않고…
운영 서버가 커널 패닉으로 죽으면 그 순간의 메모리 상태를 확인해야 원인을 알 수 있는데, 재부팅이 끝나면 그 상태는 그대로 사라진다. dmesg에 남는 마지막 몇 줄만으로는 콜스택 전체나 락 상태 같은…