제2의 비엔지니어 인생관을 꿈꾸며

Posted
Filed under Study
there has been an overflow or underflow in GC memory presure 웹페이지 에러관련해서 아래와 같은 블로그 사이트를 참조하여 긁어왔다.

여전히, 많은 닷넷 프로젝트에서 "COM" 개체를 심심치 않게 사용합니다. 물론, Interop 으로 사용하는 COM 개체 역시 참조시에 함께 제공되는 "RCW(Runtime Callable Wrapper)" 에 의해서 자원 해제가 자동으로 불려지게 됩니다. 즉, VC++ 에서는 CoCreateInstance 한 이후에 반드시 IUnknown::Release 메서드를 호출해서 명시적으로 자원을 해제해야 했지만, .NET 에서는 해당 COM 개체에 대해 Interop DLL 을 통해서 제공되는 RCW 개체가 GC(Garbage Collector) 가 구동되면서 COM 개체 자원이 같이 해제(Release) 되어 집니다.

그럼... 한번 테스트 해볼까요?

우선, ATL 프로젝트를 하나 만들고 "Simple Object" 유형의 개체를 추가한 다음, 자동 생성된 코드의 "FinalRelease" 메서드에 자원이 해제되었음을 알리는 출력문을 넣어둡니다.

// COM 개체가 해제되었을 때 불려지는 메서드
void FinalRelease()
{
::OutputDebugString("CTestObject - Released\r\n");
}

이제, 빌드하고 테스트 용 WinForm 프로젝트를 만들어서 위의 COM 개체를 참조한 다음 아래와 같이 그에 대한 RCW 개체를 사용합니다.

// COM 개체를 사용
private void Form1_Load(object sender, EventArgs e)
{
TestATLLib.TestObjectClass testObject = new TestATLLib.TestObjectClass();
}

// button1 버튼이 눌리면 GC 를 호출.
// Form1_Load 안에서 생성되었던 testObject 에 대한 RCW 개체가 해제되면서 COM 개체 역시 해제됨.
private void button1_Click(object sender, EventArgs e)
{
GC.Collect();
}

마지막으로, C/C++ 의 "OutputDebugString" 함수 호출로 인한 디버그 메시지를 VS.NET Output 창에서도 볼 수 있도록 프로젝트 속성 창에서 "Enable unmanaged code debugging" 옵션을 켭니다. (이거 안 켜두면, 아무리 Debug 빌드일지라도 메시지가 보이지 않습니다.)

이제 실행시키고, "button1" 을 누르면 "Output(출력)" 창에 "CTestObject - Released" 메시지가 출력되는 것을 볼 수 있습니다. 결국, COM 개체 해제를 명시적으로 해주지 않아도 자원이 샐 염려는 없으니 별다르게 문제가 없어보입니다. ^^

물 론, 그런 가정은 때에 따라서 맞을 수도 잇고, 아닐 수도 있습니다. 왜냐 하면, 가령 예를 들어 그 COM 개체가 DB 에 대한 연결 개체였다면 다음 GC 호출 때 까지는 DB 연결 개체가 해제되지 않고 계속 쌓여갈 테고 급기야 DB 연결이 불가능한 상황에 까지 이를 수 있습니다. 상황을 더욱 안 좋게 만드는 원인이 하나 더 있다면, 대개의 경우 개발시에는 테스트를 위해 한두번 DB 조회/수정/삭제/생성 관련 메서드를 호출해 보기 때문에 아무런 이상이 없다고 넘어가다가, 마지막 실서버에 올려서 서비스를 하게 되면 여지없이 문제가 발생합니다. 물론, 그 때는 이미 소스 코드 양이 많아진 상태이기 때문에 디버깅 및 문제 수정을 위한 적지 않은 비용이 들어가게 됩니다.

그럼, 이럴 때는 어찌해야 하느냐?

그런 경우에는 Marshal.ReleaseComObject 를 사용하시면 됩니다. 아마 닷넷 출시 이후 초기 프로젝트에서 COM+ 개체를 이용하여 DB 트랜잭션을 구현해 보신 분들은 익히 알고 계실텐데요. 그래서, 가능한 COM 개체는 다음과 같이 명시적으로 해제하는 코드를 사용해 주시는 것이 좋습니다.

private void Form1_Load(object sender, EventArgs e)
{
TestATLLib.TestObjectClass testObject = new TestATLLib.TestObjectClass();
Marshal.ReleaseComObject(testObject);
}

여기 까지는 이미 많은 분들이 아실 테고.

그런데, 최근 들어서 C++/CLI 에서의 Interop 이 많아지면서 다음과 같은 식으로 COM 개체를 사용하는 경우도 있습니다.

=== C# ===
CPPCLI.Helper.UseThisObject(pObject);

=== C++/CLI ===
public static void UseThisObject(Object ^pObject)
{
IntPtr iPtr = System::Runtime::InteropServices::Marshal::GetIUnknownForObject(pObject);
CComQIPtr<ITestObject> pTestObject((ITestObject *)iPtr.ToPointer());
}

위험하죠! 그나마 이전에 설명한 RCW 는 GC 에 의해서 자원해제라도 되지만, 위의 코드로 넘어온 COM 개체는 영원히 해제가 되지 않습니다. 오늘의 퀴즈입니다. 어디가 문제일까요? ^^ (혹시, 여러분들의 코드에서 Marshal.GetIUnknownForObject 메서드를 사용한 곳이 있다면 지금 당장 코드를 추가하시기 바랍니다.)

정답은, 첨부 파일의 예제 프로젝트 안에 있습니다.

[출처] Marshal 타입 관련 2가지 자원 해제 메서드|작성자 techshare


눼이년 블로그에서 복사해서 갖고온거다. 뭔가를 기록해야 된다는 생각에 만만한 내 블로그에 기록하는데...

문제는 난 개발자가 아닌데 왠 개발 소스를 붙여넣고 들어도 모른 객체니 뭐니 하는걸 참조하는가?라는 의문이 있겠지만 필자가 관리하는 서버에 위와 상황이 비슷한 경우를 접했기 때문이다. GC 메모리 에러 DB접속 에러및 실패라는 보도 듣도 못한 잉글리쉬 에러를 뿜어데는데 나보고 어쩌라는건지...

그래서 아는부분은 친절하게 잘가르켜주시는 타부서 최K 이 이 사이트를 찾아주었는데 내가 해결할 부분은 아니지만 이리저리 설명듣고 읽어보니 감이 오고 있다. 에러메세지가 이유없이 뜨지는 않을것이다. 그렇다고 무조건 개발자 개발이 잘못된거다 뜯어고쳐야 한다는 말을 했다간 캐발리기 일수. IT Pro가 접근하기 힘든 개발파트를 어찌 뭐라 할수 있으리오 어쩔수 없이 그냥 신뢰를 할수밖에...

역시 궁금한건 계속 물어보다보면 답이 보이기 시작한다. 구글링해서도 이것저것 자료 찾아보면 영어로 뭐라 질문한것들이 많은데 기본적인 개념을 알지 못하는 필자에게는 아직 개발자료 검색은 무리고 엔지니어 관련쪽에서 많은 자료를 찾아보는게 올바른 행동이다. 그래도 뭐가 잘못되고 뭐가 문제인지 원인만은 알아야 트러블슈팅에 삽질을 하지 않는다는것이다. 원인도 모르고 마냥 허공에 삽질을 하는건 IT Pro의 위치가 언젠가는 사라질지 모른다는 나만의 생각이다 ㅎㅎㅎ


2009/02/03 15:47 2009/02/03 15:47