24.5.1.4 gdb에서 mysqld 디버그

대부분의 시스템에서는 mysqld가 충돌 한 경우에 자세한 정보를 얻기 위해, gdb에서도 mysqld를 시작할 수 있습니다.

Linux의 일부 오래된 gdb 버전에서는 mysqld 스레드를 디버깅 할 수 있도록하려면 run --one-thread 를 사용해야합니다. 이 경우 한 번에 활성화 할 수있는 것은 하나의 스레드 만입니다. 스레드 디버깅은 gdb 5.1 쪽이 더 잘 작동하기 때문에이 버전으로 업그레이드하면 최적입니다.

gdb에서 mysqld를 실행하면 NPTL 스레드 (Linux의 새로운 스레드 라이브러리)로 인한 문제가 발생할 수 있습니다. 

다음과 같은 현상이 발생합니다.

이 경우 gdb를 시작하기 전에 셸에서 다음 환경 변수를 설정하십시오.

LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL

gdb에서 mysqld를 실행할 때, --skip-stack-trace 를 사용하여 스택 추적을 해제하고 gdb에서 세그먼트 오류를 포착 할 수 있도록해야합니다.

MySQL 4.0.14 이후에서는 mysqld에 --gdb 옵션을 사용하십시오. 그러면 SIGINT 에 대한 인터럽트 핸들러 (mysqld를 ^C 로 정지하고 중단 점을 설정하기 위해 필요합니다)가 설치되어 스택 트레이스와 코어 파일 처리가 무효가됩니다.

새 연결이 항상 다수 발생하면 gdb는 오래된 스레드의 메모리를 해제하지 않기 때문에 gdb에서 MySQL을 디버깅하는 것은 매우 어렵습니다. 이 문제를 해결하려면 thread_cache_size 를 max_connections + 1으로 동일하게 설정하고 mysqld를 시작합니다. 대부분의 경우 --thread_cache_size=5' 를 사용하는 것만으로도 상당히 개선됩니다.

SIGSEGV 시그널이 발생 mysqld가 비정상적으로 종료 할 때 Linux 코어 덤프를 취득하는 경우, --core-file 옵션을 지정해 mysqld를 시작합니다. 이 코어 파일은 mysqld가 비정상적으로 종료 된 이유를 찾기 위해 도움이 될 수있는 백 트레이스를 만드는 데 사용할 수 있습니다.

shell> gdb mysqld core
gdb>   backtrace full
gdb>   quit

섹션 B.5.4.2 "MySQL이 계속 충돌하는 경우의 대처 방법" 을 참조하십시오.

Linux에서 gdb 4.17.x 이상을 사용하는 경우 다음의 정보를 가진 .gdb 파일을 현재 디렉토리에 설치하십시오.

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

gdb를 사용한 스레드 디버깅에 문제가있는 경우, gdb 5.x를 다운로드하고이를 대신 시도하십시오. 새로운 버전의 gdb는 스레드 처리가 매우 개선되고 있습니다.

mysqld을 디버그하는 방법의 예를 보여줍니다.

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Do this when mysqld crashes

위의 출력을 버그 리포트에 포함 섹션 1.7 "질문이나 버그를보고하는 방법" 의 단계를 사용하여 버그 보고서를 제출할 수 있습니다.

mysqld가 중단 된 경우에는 strace / /usr/proc/bin/pstack 와 같은 시스템 도구를 사용하여 mysqld가 중단 된 장소를 조사 할 수 있습니다.

strace /tmp/log libexec/mysqld

Perl의 DBI 인터페이스를 사용하는 경우, trace 메소드를 사용하거나 DBI_TRACE 환경 변수를 설정하여 디버깅 정보를 설정할 수 있습니다.