IT

CMFCButton memory leak 버그

하트바다 2012. 5. 30. 09:21

모르긴 몰라도 MS에 있는 사람들이 나보다는 훨씬 똑똑할꺼라 생각하여 나는 MS의 버그를 만날 수 있으리란 생각을 안했다.

그런데 정말 쌩뚱맞은 곳에서 발견!!!

이번에 급하게 프로젝트 컴파일 할 일이 있어서 버튼을 VS2010 에 올라와 있는 CMFCButton 을 사용했다. 나름 세밀한 기능이 CButton을 Subclassing 하는 거 보다는 믿음이 갔기 때문이겠지?

그런데 이놈을 사용해서 컴파일 하니 아래의 memory leak이 발생!!!


Detected memory leaks!

Dumping objects ->

f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\plex.cpp(29) : {6669} normal block at 0x04512CD8, 164 bytes long.

 Data: <              zx> 00 00 00 00 00 00 00 00 C5 9D 1C 81 F8 B8 7A 78 

f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\map_sp.cpp(83) : {6668} normal block at 0x04512B38, 68 bytes long.

 Data: <     ,Q         > 00 00 00 00 DC 2C 51 04 00 00 00 00 00 00 00 00 

f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtooltipmanager.cpp(70) : {6667} client block at 0x04512C08, subtype c0, 144 bytes long.

a CToolTipCtrl object at $04512C08, 144 bytes long


이런 글이 CMFCButton 하나 마다 세문장씩 쭉쭉 써진다~!!!!  처음에는 내가 문제가 있겠거니 했으나 MS의 예제는 잘 되고 나만 안되는 상황!!!  왜 나만 갖구 그래!!!

한참을 뒤진 후에 알게 되었다. 그것도 MFC developer 아저씨의 공식 블로그 에서...

In every release we need to balance our investment across the various areas of the product. However, we still believe that MFC is the most fully-featured library for building native desktop applications. We are fully committed to supporting and maintaining MFC at a high level of quality. Here’s a short list of some of the issues that we fixed in MFC for Visual Studio 11:

  • Addressed executable size of applications linked statically to MFC
  • Fixed DLLMain best practices violations by deferring initialization of the afxGlobalData structure
  • Fixed over 220 bugs, nearly 100 of which were reported by customers via the Connect web site
  • Fixed a large number of paint/draw issues (in toolbars, splitters, theme switches, etc.)
  • Fixed several memory leaks (in CMFCVisualManager and CMFCButton classes)
  • Added a number of missing exports (methods and data) to the MFC import libraries

라는구먼...

그럼 또 VS11 로 가야 고칠 수 있단 말인가...  훔훔...