2011-08-16 3 views
2

저는 몇 주 동안 기본 CLR 호스팅을 사용하고 있습니다. 처음에는 꽤 잘 돌아갔다. 하지만 나중에 응용 프로그램의 일부가 힙 손상을 일으키는 것으로 나타났습니다. 이 문제는 CLR 시작으로 인한 것임을 알았습니다. (코드의 짧은 버전은 다음을 참조하십시오.)CLR4 호스팅 인터페이스로 인해 힙 손상이 발생하고 있습니까?

#pragma comment(lib, "mscoree.lib") 
#include <mscoree.h> 
#include <metahost.h> 
#include <comdef.h> 
#import "mscorlib.tlb" raw_interfaces_only   \ 
    high_property_prefixes("_get","_put","_putref")  \ 
    rename("ReportEvent", "InteropServices_ReportEvent") 

using namespace mscorlib; 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    HRESULT hr; // In fullversion used for error detection - but here unused. 
    PCWSTR pszVersion = L"v4.0.30319"; 
    ICLRMetaHost* lpMetaHost = NULL; 
    ICLRRuntimeInfo* lpRuntimeInfo = NULL; 
    ICorRuntimeHost* lpRuntimeHost = NULL; 
    _AppDomainPtr spAppDomain = NULL; 
    BOOL bLoadable = false; 
    IUnknownPtr spAppDomainThunk = NULL; 

    CLRCreateInstance(CLSID_CLRMetaHost, IID_ICLRMetaHost, (LPVOID *)&lpMetaHost); 
    // After this line i can "late detect" 6 array bound heap corruptions in process memory. 

    lpMetaHost->GetRuntime(pszVersion, IID_ICLRRuntimeInfo, (LPVOID *)&lpRuntimeInfo);  
    lpRuntimeInfo->IsLoadable(&bLoadable); 
    lpRuntimeInfo->GetInterface(CLSID_CorRuntimeHost, IID_PPV_ARGS(&lpRuntimeHost)); 
    lpRuntimeHost->Start(); 
    lpRuntimeHost->GetDefaultDomain(&spAppDomainThunk); 
    spAppDomainThunk->QueryInterface(IID_PPV_ARGS(&spAppDomain)); 
    spAppDomainThunk->Release(); 
    // Now I can "late detect" up to 9 array bound heap corruptions in process memory. 

    return 0; 
} 

Rational Purify Exception

이를 방지하는 방법에 어떤 아이디어? 현재 어떤 경우에는 여전히 작동하지만 애플리케이션이 커질수록 오류 가능성이 기하 급수적으로 증가합니다.

+0

오류를 확인하지 않고 NULL에 대한 포인터를 초기화하지 않습니다. 코드의 전체 버전에서 오류를 확인합니까? – Justin

+0

예 그러므로 HRESULT는 정의되었지만 내 발췌문에서는 사용되지 않았습니다. 가능한 한 짧은 질문을 계속하기 위해 오류가 없습니다. 나는 나의 질문에 그 점을 유의할 것이다. –

+0

코드에 문제가없는 것 같습니다. spAppDomainThunk-> Release() 직후에 반환하면 정화 오류가 발생합니까? – elevener

답변

0

위의 코드를 시각적으로 검사해도 힙 손상을 일으킬 수있는 것이 나타나지 않지만 AppVerifier + Windbg를 사용하여이를 감지하십시오. 그것을하는 방법에 관한 약간 정보는 여기있다 http://blogs.msdn.com/b/lagdas/archive/2008/06/24/debugging-heap-corruption-with-application-verifier-and-debugdiag.aspx. AppVerifier는 실제로 스택 (프레임, 호출)에서 힙을 손상시키는 위치를 정확하게 지적합니다.

+0

AppVerifier와 windbg는 합리적인 puritfy와 완전히 똑같습니다. 위의 오류를 보여줍니다. 이를 향한 나의 연구 결과는 이러한 오류가 CLR 내부에서 하드 코드 된 것으로 보이며 시스템 특정 변수 등을 감지하는 데 사용될 수 있다는 것입니다. 즉, 마이크로 소프트가 문제를 해결하기 위해 약간의 해킹을 한 것처럼 보입니다.이 오류는이 9 가지 오류에 나타납니다. BTW. 이러한 오류와 상관없이 CLR 호스트는 정상적으로 작동합니다. –