GDB를 이용한 코어 덤프(core dump) 분석 가이드

GDB를 이용한 MSSQL 코어 덤프(core dump) 분석 가이드

1️⃣ 문제 원인

프로세스가 비정상 종료(SIGSEGV 등)되면서 코어 덤프가 발생했습니다. 분석 결과, mssql_packet_add() 및 xlist_realfree() 함수 내부에서 메모리 접근 오류가 발생한 것으로 추정됩니다. 이는 일반적으로 NULL 포인터 참조, 이중 해제(double free), 혹은 메모리 손상(heap corruption)에서 비롯됩니다.

2️⃣ GDB 분석 절차

# 코어 파일 생성 형식 지정
echo "core.%e.%p" > /proc/sys/kernel/core_pattern

# (systemd-coredump 비활성화 예시)
echo "/usr/lib/systemd/systemd/coredump %P %u %g %s %t %c %h %e" > /proc/sys/kernel/core_pattern

# DEBUGINFOD 자동 다운로드 비활성화
export DEBUGINFOD_URLS=

# 코어 분석 시작
gdb /usr/bin/mybinary core.mybinary.12345

# 스택 백트레이스 로그 저장
set logging file bt.log
set logging on
bt
thread apply all bt full
set logging off

3️⃣ GDB 백트레이스 예시 (MSSQL 관련)

#0  xlist_realfree (xl=0xb70c6fee37) at xlist.c:103
        xn = <optimized out>
        nextxn = <optimized out>
        __PRETTY_FUNCTION__ = "xlist_realfree"
#1  0x00000000005d375a in mssql_packet_add (sessp=0x7fd2d0060920, xn=0x7fd2b4e2a530) at mssql.c:1901
        tdsp = 0x7fd2d0066140
        xp = 0x7fd2b57c3550
        datasize = 235
        ret = 0
        istds = <optimized out>
        skipsize = <optimized out>
        curp = <optimized out>
        endp = <optimized out>
        tdshdr = {hdtype = 125 '}', hdstatus = 225 '\341', hdsize = 0, hdspid = 0, hdnumber = 0 '\000', hdwindow = 23 '\027'}
#2  0x00000000005d49da in mssql_packet_gateway (...) at mssql.c:1180
#3  0x00000000005d53d8 in tap_tdspacket (...) at mssql.c:674
#4  0x00000000005d58f5 in mssql_packet_tap (...) at mssql.c:548
#5  0x00000000005d5ffe in thread_mssql (...) at mssql.c:302
#6  0x00007fd35c1701ca in start_thread () from /lib64/libpthread.so.0
#7  0x00007fd35a536e73 in clone () from /lib64/libc.so.6

위 스택에서는 xlist_realfree() → mssql_packet_add() → thread_mssql() 순으로 호출되어 있으며, 메모리 해제 관련 로직(xlist_realfree)에서 비정상 접근이 발생했습니다. 특히 xl=0xb70c6fee37처럼 비정상적인 주소 패턴이 보이는 경우, 잘못된 포인터가 전달된 사례로 볼 수 있습니다.

4️⃣ 상세 분석 예시

(gdb) f 3
(gdb) info locals
(gdb) info args
(gdb) p sessp->sesstype
(gdb) p *sessp

위 명령을 통해 각 프레임의 지역 변수와 인자값을 확인할 수 있습니다. 특히 구조체(sessp) 내부 필드를 출력하면 어떤 세션 정보가 비정상 상태로 전달되었는지를 확인할 수 있습니다.

5️⃣ 조치 및 복구 절차

• 심볼 정보를 확보 (debuginfo-install) 후 재분석
• xlist_realfree() 내부 free 시점 검토 (중복 해제 여부 확인)
• 세션 포인터(sessp) 유효성 검사 추가
• 메모리 풀 관리 로직(mssql_packet_add / gateway) 점검

6️⃣ 결과 요약

이번 crash는 메모리 해제 루틴(xlist_realfree) 호출 시점에서 잘못된 포인터가 전달되어 발생한 것으로 판단됩니다. GDB를 활용하면 문제 함수의 호출 스택, 변수 상태, 메모리 주소 이상 여부를 정밀하게 분석할 수 있습니다.

7️⃣ 기본 오류 대응 4단계

1. 코어 덤프 생성 설정 확인 (/proc/sys/kernel/core_pattern)
2. GDB로 스택 및 변수 분석
3. 심볼/소스 기반의 문제 함수 추적
4. 포인터·메모리 검증 및 재현 테스트 진행