닷넷 프로파일러의 또 다른 응용: Visual Studio 2010 Historical Debugging
Visual Studio 2010에서 특출나게 자랑하는 것 중의 하나가 바로 "Historical Debugging" 기능입니다. 처음 Visual Studio 2010에 익숙치 않은 분들은 오른쪽 영역을 너무 커다랗게 잡아먹는 "Debug History" 창이 부담스러워 그냥 닫아버리는 분들이 계실 텐데요.
도대체 어떤 기능이길래 그리 대단한가... 확인하고 싶은 분들은 다음의 글을 참조하시면 좋겠습니다.
How Does VS2010 Historical Debugging Work?
; http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/16/how-does-vs2010-historical-debugging-work.aspx
저 같은 경우 "Historical Debugging" 기능을 보면서 나름 생각해 본 유용한 활용예가 Process Attach를 시켜서 소스 코드가 없는 다른 응용 프로그램의 문제를 "Historical Debugging" 기능으로 살펴보는 것도 좋은 방법으로 보였습니다. 하지만, 시도를 해보면 알겠지만 Process Attach 방식으로 디버깅을 시작하면 "Historical Debugging" 기능이 동작하지 않습니다. 다소 실망은 했지만 그냥 거기서 끝냈는데, 바로 위의 글을 읽으면서 그것이 왜 불가능한 것인지를 알게 되었습니다.
It's probably not too big a surprise that Historical Debugging is using IL rewriting to inject its hooks into the application as about the only other way would be to require you instrument the IL on disk before you run the binary
아하...! 프로파일링의 JITCompilationStarted 콜백 단계에서 원하는 IL 코드를 임의의 위치에 넣어버리는군요. 이것은 "Historical Debugging" 기능은 IL 코드가 기계어로 컴파일되기 이전에나 정상적으로 동작할 수 있다는 것입니다. 현재 실행되고 있는 응용 프로그램은 이미 많은 부분에서 JIT 컴파일링이 일어났고 설령 아직 실행되지 않은 메서드가 있다 하더라도 프로파일링을 프로그램 실행 이후에 걸 수 없다는 점을 생각하면 역시나 Process Attach 방식으로는 안된다는 점이 이해가 됩니다. (참고로, CLR 4.0에서는 일부 기능에 대해서 프로그램 실행 중간에 프로파일링을 걸 수 있습니다.)
그래도... ^^ 대단한 사실을 하나 알게 되었습니다. "Historical Debugging" 기능을 보면서 JITCompilationStarted의 활용예가 이 정도까지도 가능하다는 것! 하긴, 원하는 IL 코드를 임의의 위치에 넣어버리니 ^^ 못 할 게 없어 보입니다. 생각 여하에 따라서 이 부분은 비단 마이크로소프트뿐만 아니라 우리에게도 멋진 3rd-party 컨트롤을 만들 수 있는 여지로 남습니다.
오랫만에 Visual C++ 프로젝트를 만져 볼 기회가 왔군요. ^^ 위의 기사에서 가리키는 글에 공개된 NETProfilingAPI.exe 예제를 다운로드해서 압축을 풀어 돌려보았습니다. 오호... 그런데 전혀 동작을 안하는군요.
그래도 나름 COM 개체로 한 시대를 풍미했던 성태 아니겠습니까? :)
원인 파악에 들어가 보니, "ConstraintsChecker.cpp" 파일에 구현된 CConstraintsChecker::QueryInterface 메서드의 내부 코드에 문제가 있었습니다.
HRESULT CConstraintsChecker::QueryInterface( REFIID riid, void** ppv )
{
if ( riid == IID_IUnknown )
*ppv = static_cast<IUnknown*>( this );
else if ( riid == IID_ICorProfilerCallback )
*ppv = static_cast<ICorProfilerCallback*>( this );
else
{
*ppv = NULL;
return E_NOINTERFACE;
}
reinterpret_cast<IUnknown*>(*ppv)->AddRef();
return S_OK;
}
CLR 1.x에서는 프로파일링 콜백 인터페이스가 ICorProfilerCallback만 제공되었지요. 그 후 CLR 2.0에서 ICorProfilerCallback2 인터페이스가 새롭게 제공이 되었는데, 문제는 CLR 2.0 이후 버전에서는 대상 프로파일러 개체에 QI를 할 때 ICorProfilerCallback은 하지 않고 ICorProfilerCallback2로만 물어본다는 것입니다.
따라서, 위의 코드가 CLR 1.x 및 2.0 이후의 버전에서 모두 동작시키도록 만들기 위해서 다음과 같이 수정해 주시면 됩니다.
HRESULT CConstraintsChecker::QueryInterface( REFIID riid, void** ppv )
{
if ( riid == IID_IUnknown )
*ppv = static_cast<IUnknown*>( this );
else if ( riid == IID_ICorProfilerCallback )
*ppv = static_cast<ICorProfilerCallback*>( this );
else if (riid == IID_ICorProfilerCallback2)
*ppv = static_cast<ICorProfilerCallback*>( this );
else
{
*ppv = NULL;
return E_NOINTERFACE;
}
reinterpret_cast<IUnknown*>(*ppv)->AddRef();
return S_OK;
}
물론, 코드 변경 이후에는 잘 동작합니다.
CLR 프로파일러에서 "F5 디버깅"이 가능하면 코드 분석이 더욱 편리하겠지요. 이에 대해서는 다음의 글을 참고하십시오.
디버깅 방법 - CLR 프로파일러
; https://www.sysnet.pe.kr/2/0/258
자... 이제 이걸로 무엇을 하면 좋을런지... 우리들의 상상력이 문제겠군요. ^^
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]