동작이 멈추었다는 것에 대한 정확한 설명이 부족하지만, 사용자에게 응답하지 않는 것을 가정으로 볼 때, app에 따라 너무 많은 상황이 존재합니다.
Application을 고치지 않고, 확인할 수 있는 방법은, 간단히 생각해보면, 먼저 해당 app의 CPU usage를 조사하는 방법도 있겠지만, 이는 수치 계산 관련 코드에서 무한 루프에 빠졌다면, 의미가 없습니다. CPU usage가 낮은 경우에도, incoming data를 기다리고 있을 경우도 있으므로, app가 죽었다고 보기 힘듭니다.
말씀하신대로 app를 고쳐서 특정 message나 signal을 보내, 응답 여부를 test하는 것이 가장 현실적인 방법이겠지만, 이것도 잘 만들어야 합니다. 예를 들어 app가 1. main job을 처리하는 thread, 2. 동작 멈춤을 판단할 message를 처리하는 thread로 구성되어 있을 경우, thread 1이 멈추더라도 thread 2가 동작하면, 제대로 동작하는 것으로 오인할 수 있기 때문입니다.
그런 software를 작성하는게 아니고, 단순히 개발하는 프로그램이 멈춘 것 같은 증상을 보인다면 GDB를 attach해서, 해당 call stack을 살펴보는 것으로 확인할 수 있습니다.
동작이 멈추었다는
동작이 멈추었다는 것에 대한 정확한 설명이 부족하지만, 사용자에게 응답하지 않는 것을 가정으로 볼 때, app에 따라 너무 많은 상황이 존재합니다.
Application을 고치지 않고, 확인할 수 있는 방법은, 간단히 생각해보면, 먼저 해당 app의 CPU usage를 조사하는 방법도 있겠지만, 이는 수치 계산 관련 코드에서 무한 루프에 빠졌다면, 의미가 없습니다. CPU usage가 낮은 경우에도, incoming data를 기다리고 있을 경우도 있으므로, app가 죽었다고 보기 힘듭니다.
말씀하신대로 app를 고쳐서 특정 message나 signal을 보내, 응답 여부를 test하는 것이 가장 현실적인 방법이겠지만, 이것도 잘 만들어야 합니다. 예를 들어 app가 1. main job을 처리하는 thread, 2. 동작 멈춤을 판단할 message를 처리하는 thread로 구성되어 있을 경우, thread 1이 멈추더라도 thread 2가 동작하면, 제대로 동작하는 것으로 오인할 수 있기 때문입니다.
그런 software를 작성하는게 아니고, 단순히 개발하는 프로그램이 멈춘 것 같은 증상을 보인다면 GDB를 attach해서, 해당 call stack을 살펴보는 것으로 확인할 수 있습니다.
--
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://www.cinsk.org/cfaqs/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/
댓글 달기