DumpClass

안녕하세요 대학생 개발자입니다.

이번 글에서는

예외에 대한 핸들링에 대한 부분과 덤프클래스에 대해서 정리를 해보려고합니다.

우리가 0을 분모로 나눗셈을 하려고 하거나 혹은 new에서 메모리가 할당이 되지 않은 이런 경우를 포함 다수 경우에 예외가 발생하게 됩니다.

그리고 이 예외는 c runtime library가 처리를 하거나 혹은 os가 처리할 수 도있겠죠.

우리는 이 예외에대한 모든 핸들링 처리를 우리 코드로 돌리는 작업을 할겁니다.

그리고 예외가 발생했을때 덤프를 남겨 우리가 확인할 수 있게 할겁니다.

 

그리고 최근 글을 보신분들은 아시겠지만 덤프에대한 구현을 하려는게 아니라 왜 덤프를 써야하는지 왜 에러를 직접 핸들링 해야되는지에 대한 베이직한 이론내용이 들어가지 구현에 대한 부분은 언급하고있지 않습니다.

그럼 시작하도록 하겠습니다.

 

굳이 왜 덤프를 남기는거지?

우선 왜 이렇게 하느냐가 필요하겠죠.

문제가 생겼을때에 대한 예외처리는 당연히 1차적으로 하위 레이어에서(crt,os등) 처리할겁니다.(컴퓨터가 뻗지않고 잘 도는 이유가 이것때문입니다)

하지만 서버가 라이브 서비스중에 혹은 런타임중에 문제가 생긴다면 하위 레이어에서 커버를 하게 될것이고 우리는 그 에러를 확인할 방법이 없어지게됩니다.

널포인터를 찔렀을때 나는 크래시 핸들링을 우리가 하지 않기 때문에 왜 널포인터를 찔렀는지 확인할 방법이 사라진다는것이죠.

그렇기 때문에 덤프가 필요하겠죠...

그리고 모든 에러의 경우에 우리의 덤프가 남았으면 하는 바람이 있기 때문에 모든 예외를 우리가 핸들링할 필요성이 있었습니다.

msvs에 디버거가 존재하는데 왜 이런게 필요한가 라고하신다면 문제가 있습니다.

 

첫째로 디버거를 물려놓은 채로 라이브 서비스를 하기에는 너무 느립니다.

당연하겠죠 다른 프로세스에서 후킹을 된 상태로 코드가 돌기 때문에 느릴겁니다.

느린 문제를 해결하기 위해서 그냥 돌리자니 언제 어디서 문제가 터질지 알수없게 될겁니다.

라이브 서비스중에 갑자기 서버가 죽었는데 확인할 방법이없다? 그것만큼 답답한 상황도 없을것 같습니다.

당연히 모든 예외에 대한 핸들링 처리를 덤프를 뽑아내는 방식으로 처리하게 만들어 버릴겁니다.

 

 

두번째로 멀티스레드 환경에서 디버거를 물린채로 돌리면 너무 느려서 버그가 발생하지 않습니다.

멀티스레드로 코드가 돌때는 매우 다양한 케이스들이 존재하게 될거고 우리 머릿속으로 생각하기 힘든 문제가 많이 나타나게 될겁니다.

그리고 그 문제들은 빨리 나올수록 우리에게 이득이죠.

만약 디버거를 물려놨다면 디버거때문에 느려진 성능으로 나야할 문제가 발생하지 않을수도 있으니 우리는 실제와 똑같은 상황(그냥 실행파일만 실행시킨상태)로 만들어서 테스트를 해야할 필요가 있습니다.

 

결과적으로 느리기때문에 생기는 두가지 문제점이 있었습니다.

뭐 일단 단순히 봤을땐 에러에 대한 핸들링 정도만 해주면 될 것 같지만 우리에게는 문제가 여전히 많이 있습니다.

그 문제는 차차 알아보도록하고 우선은 덤프에 대한 얘기를 좀 해봐야 할 것 같습니다.

 

덤프가 뭔가요?

우선 우리에게 가장 중요한건 덤프가 무엇이고 왜 남겨야하는지입니다.

그리고 왜 남겨야 하는지에 대한 부분은 위에서 말씀드렸습니다.

 

그럼 덤프가 뭔지에 대한 부분에 대한 내용이 필요할겁니다.

우선 덤프는... 그냥 그 상황 그당시의 메모리 자체를 의미합니다.

그리고 우리의 경우에는 지금 프로세스가 가지고 있던 모든 메모리들을 보조기억장치로 옮겨놓은 파일이라고 보시면 될 것 같습니다.

 

우리는 그 덤프라는걸 보고 문제를 분석할것이구요...

msvs에서 디버거를 돌렸을때 크래시가 나거나 혹은 중단점을 걸었던 그 상황과 완벽하게 동일하게 상황이 연출될겁니다.

대신 우리는 예외 핸들링을 통해서 예외가 발생했을때 덤프를 뽑아내는 작업만 하면 되겠습니다.

 

주의할점은 없나요?

어... 주의하실점이 있습니다.

아마 여러분들이 코드를 이상하게 짜지 않는이상 얼토당토 안한 곳에서의 크래시는 발생하지 않을겁니다.

대부분의 경우 멀티스레드 환경에서 공유자원을 사용하던 도중 문제가 생길겁니다.

아마 문제가 생기면 연쇄적으로 다른 스레드까지 문제가 생길 확률이 높습니다.

그 결과 하나의 프로세스에서 여러 스레드가 덤프를 남기로 가는 과정이 생길 수 있게 되겠죠.

우리는 이점을 잘 확인해야 될겁니다.

당연히 모두가 문제가 났으니 들어왔을 것이지만 최초의 문제만 우리는 덤프로 남길겁니다.

당연히 CreateFile에서 이미 열려있는 파일에 대해서 동시에 접근하는 경우는 없을 것입니다만 이미 쓰고 닫은 파일을 다시 열어서 또 쓰게 되는 경우는 우리 덤프가 덮어써지게 될테니 당연히 최초 하나의 스레드에서만 사용할 수 있게 해야될 것입니다.

그리고 이경우에는 대부분 최초의 문제때문에 파생되어서 터지는 경우가 대다수이기 때문에 최초의 문제만을 가지고 갈겁니다.

 

그래서 결론은

뭐든간에 문제가 생겼을때 최고로 좋은건 우리가 아는 범위내에서 문제가 생기는게 제일 좋겠죠.

하지만 우리가 알지 못하는 범위에서의 문제가 멀티스레드 환경에서는 분명히 생길겁니다.

그리고 멀티스레드 상황에서는 그 알수없는 문제때문에 터졌을때 어디서 터졌는지를 알아도 도대체 왜 죽었는지 판단하는것이 어렵습니다.

그런 상황에서 우리에게 어디에서 문제가 터졌는지 조차도 알수없다고 한다면 당연히 원인을 찾는것은 영원히 불가능일 것입니다.

실제 파일이나 콘솔로그로는 한계가 분명히 존재합니다.

콘솔로그나 파일io등은 블로킹에 걸리기 때문에 거기서 일부 동기화가 잡혀버리게 되고 문제가 발생할 확률이 줄어들게 되죠...

그럼 우리에게 남은것은 메모리로그와 문제가 생겼을때 그 메모리를 온전히 보관하고 있는 덤프밖에 없습니다.

 

그러므로 문제가 생겼을때 우리가 문제를 파악할 수 있게 하기위해서는 메모리를 뽑아내고 그걸 토대로 분석하는 습관이 필요할 것입니다.

 

이런 결론이 나오는군요.

 

저는 그럼 이쯤에서 글을 마무리 하려고 합니다.

오늘도 긴 글 봐주신 여러분들께 정말 감사드립니다.

다음글에서는 더 좋은 내용으로 돌아오도록 하겠습니다.

그럼 안녕히계세요