|
|
|
|
디버그 기술 |
|
버그의 대별버그에는 몇 개의 종류가 있어, 발생하는 현상에 특징이 있는 경우가 있습니다. 프로텍션 에러가장 발생율의 높고 광범위하게 검출됩니다. 프로텍션 에러가 발생했을 경우, 메모리 파괴를 일으킵니다.
(처치) 스텝 실행
(처치) 자원의 감소 경향을 정기적으로 확인해 리크 경향을 파악.
(처치) 가속 시험.통신 빈도를 높이거나 하고 빈도가 높아지면 배타 제어 부족
등의 설계 불량을 원인으로 한 것일 가능성도 높다.
거동 의심프로텍션 에러나 프리즈를 일으키는 일 없이, 동작이 부진이면서 우선 움직여 버리는 타입대로 해 제삼자 처리가 영향을 주고 있다.
(처치) INscope등의 트레이스 툴의 사용.비정상으로 처리 시간을 소비한다
스레드나, 배타 락이 없는지, 메시지 교환의 타이밍
은 설계 대로인가···등 등 스렛드간의 제휴를 중심으로 조사합니다.
(처치) 자원의 감소 경향을 정기적으로 확인해 리크 경향을 파악.
카즈키능의 정지예를 들어 통신만 있을 때로부터 끊어진다고 하는 케이스. 복합적인 요인도 생각할 수 있어 조사가 곤란합니다.
(처치) INtimeExplorer등의 툴을 이용해 스렛드 상태를 열람합니다.
외부 접점 출력을 묻고 처리를 하고 있는지를 확인합니다.
Interrupt 결핍
Interrupt처리를 가질 때, 본래 하드웨어로부터 발생해야 할 Interrupt 가 발생하고
있지 않는 것에 기인하는 경우가 있다.
(처치) 인터럽트 처리중에 외부 접점 출력을 묻어 확인한다.SDM 데바
가를 이용해 핸들러에 브레이크 포인트를 설치하는 등 방법
을 취합니다.또 PIC의 인터럽트 마스크 상태, 타겟 디바이스의
mask register, 인터럽트 요인 레지스터를 채취하는 등.
Interrupt 처리 논리의 재확인, 지연의 설치등이 필요한
경우도 있습니다.
장시간의 운용중에 발생
장시간의 운용으로 발생하는 것에서는 리크의 경향이 있다. 특히 핸들 리크는 시스템 전체를 예측 불가능한 불안정 상태로 하는 일이 있다. 가장 고빈도로 동작하는 처리가 리크의 영향을 받기 쉬운 경향도 있다. (처치) 자원의 감소 경향을 정기적으로 확인해 리크 경향을 파악.
프리즈프리즈의 조사는 단계적으로 실시한다.
(처치) 블루스 클린의 발생은 전RT프로세스에 case NT_BLUE_SCREEN:
으로서 통지되므로 이것을 훅 한다. 고우선도 RT스레드는 동작을 계속하므로''heimlich.rta 툴''
등에서 판단할 수 있다.
어플리케이션 루프의 혐의
어플리케이션하늘 루프에 빠지는 것으로 리얼타임 OS의 구조상, 우선도의 낮은 처리는 디스팟치 되지 않게 된다.외관상 Windows는 동작하지 않지만, 우선도의 높은 스렛드나 끼어들어 처리는 구동한다.Windows 스레드와의 제휴를 가지는 처리를 실행하면(예를 들어 print) 블록 해 버린다. (구체적인 예) while( 1 ){ i++; } (처치) 고우선도 RT스레드는 동작을 계속하므로''heimlich.rta 툴'' 등에서 판단할 수 있다.
OS코어로의 프로텍션
어플리케이션 프로세스로부터, 시스템 프로세스에 점프 한 앞의 처리중에 프로텍션을 일으키면 SDM가 기능해 시스템이 halt 하는 경우가 있다. (처치) 시리얼 단말의 접속
인터럽트 처리기내에서의 프로텍션
인터럽트 처리기 처리 중에서 발생하는 프로텍션이 SDM를 개시했기 때문에 시스템이 halt 하고 있는 경우, 또는 스택 프로텍션을 일으키고 있는 경우가 있다. (처치) 시리얼 단말의 접속
(구체적인 예)
Disable();
_disable();
_asm{ cli };
(처치) 상기와 같은 코드의 사용이 없는 것을 재확인하는
(처치) 시리얼 단말의 접속.세치기 클리어 처리 누락의 재확인.
|
