다음 문제는 커널 디버거와 관련됩니다.
x86 플랫폼의 Solaris 10 OS에서 신호 처리기가 있는 신호를 작동하거나 전달하는 프로그램을 디버그하는 dbx 디버거가 사용 중이면 dbx가 디버거 중단을 일으킬 수 있는 커널에서 예기치 못한 SIGTRAP 신호를 받을 수 있습니다. 이러한 상황은 dbx가 단일 스테핑, 중단점에서 실행, 런타임 확인(Runtime Checking, RTC) 데이터 수집 또는 신호 트랩핑에 따라 달라지는 기타 모든 작업을 수행 중인 경우 발생할 수 있습니다.
경우에 따라 dbx가 중단될 때 dbx에서 예기치 못한 SIGTRAP 신호에 대한 경고를 표시합니다. 예를 들면 다음과 같습니다.
dbx: internal warning: unexpected SIGTRAP! |
다른 경우 dbx는 SEGV 신호 수신을 나타냅니다. 예를 들면 다음과 같습니다.
signal SEGV (no mapping at the fault address) in main at line 29 in file "test.c" |
이 경우 사용자가 cont -sig SEGV 명령을 입력하여 SEGV 신호로 계속 실행하면 dbx에서 예기치 않은 SIGTRAP 경고를 표시합니다.
이 버그는 커널 패치 127112가 설치된 경우 x86 플랫폼의 Solaris 10 OS에서 처음 발견되었습니다.
해결 방법: 커널 패치 127112를 설치하지 마십시오. 이 커널 패치가 이미 설치된 경우 제거하십시오. 이 버그에 대한 자세한 내용은 http://developers.sun.com/sunstudio/support/news/index.jsp에서 Sun Studio Support News 페이지를 참조하십시오 .
dbx 디버거가 특정 64비트 실행 파일 및 라이브러리를 처리하는 중 메모리 액세스 오류와 함께 종료합니다. 하지만 이 문제가 해당 64비트 객체를 정상적으로 사용하는 데 영향을 주지는 않습니다. 다음 예제와 유사한 오류 메시지가 표시됩니다.
dbx: internal error: signal SIGBUS (invalid address alignment) |
해결 방법: mdb 디버거 또는 Solaris 동적 추적 기능을 대신 사용합니다. 이러한 방법을 사용하면 64비트 객체를 사용하는 프로세스를 진단할 수 있습니다.
라이브 시스템을 디버깅하기 위해 Solaris 커널 디버거를 실행 중인 시스템에서는 불완전한 오류 메시지와 함께 루프가 발생할 수 있습니다. OpenBoot PROM의 마스터 CPU가 변경될 때 이 루프가 발생합니다. 시스템을 재설정하면 시스템이 복원되어 다시 작동합니다. 그러나 원래 실패에 대한 추적이 없어지므로치명적 재설정에 대해 진단을 수행할 수 없습니다.
해결 방법: 시스템이 PROM 수준일 때 OpenBoot의 ok 프롬프트가 표시됩니다. 여러 CPU가 있는 시스템에서는 ok 프롬프트 앞에 중괄호로 묶인 숫자가 표시됩니다. 이 숫자는 시스템에서 활성 상태인 CPU를 나타냅니다. PROM 수준에서 디버그 세션을 실행하려면 다음 단계를 수행합니다.
다음 명령을 입력하여 pil을 f로 올립니다.
{0} ok h# 0f pil! |
switch-cpu 명령을 사용하여 현재 활성 상태인 CPU에서 다른 CPU로 선택적 전환합니다. 예를 들어, CPU #0에서 CPU #1로 전환하려면 다음 명령을 입력합니다.
(0) ok 1 switch-cpu |
이제 ok 프롬프트 앞에는 전환된 CPU 번호가 표시됩니다.
{1} ok |
디버거를 실행합니다.
디버거 세션이 끝나면 reset-all 명령을 실행하여 시스템을 정상적인 상태로 되돌립니다.
가장 최신 버전의 OpenBoot PROM으로 시스템을 업그레이드해야 합니다.