[vtkusers] RE:Comment on: *The solution* Re: Access violations in MFC sample

[Andrew J. P. Maclean]

This is really strange. The memory leaks you are referring don't seem to
be related to João problem. I am sure that he was referring to access
violations not memory leaks. Applying João's corrections does not fix
the memory leaks.

I reiterate that there are no access violations with the sample code. I
suspect that the other issue of memory leaks is being caused by
mismatched new/delete operators somewhere in the guts of vtk. It is
definitely related to something in the exiting of the code because
opening/closing multiple views doesn't seem to alter the number and size
of the memory leaks.
 
I am using the 2001-11-11 set of vtk files (vtk.tar.gz).
I built the dlls ( both debug and release) that I am using from these.

Interestingly I get the following set of memory leaks (they are
different from yours because I am using the individual dll's not vtkdll:
Detected memory leaks!
Dumping objects ->
{427} normal block at 0x0110EC90, 60 bytes long.
 Data: <                > 04 F2 0F 10 00 CD CD CD 20 B0 0F 10 0A 01 00
00 
{132} normal block at 0x01106AE0, 12 bytes long.
 Data: <Hello World > 48 65 6C 6C 6F 20 57 6F 72 6C 64 00 
{131} normal block at 0x01106A78, 40 bytes long.
 Data: <p               > 70 B3 0F 10 00 CD CD CD 20 B0 0F 10 15 00 00
00 
{130} normal block at 0x01106990, 168 bytes long.
 Data: <hT              > 68 54 B4 00 00 CD CD CD 20 B0 0F 10 1F 01 00
00 
{129} normal block at 0x011068E8, 108 bytes long.
 Data: <|               > 7C CC 0F 10 00 CD CD CD 20 B0 0F 10 13 00 00
00 
{128} normal block at 0x01106840, 108 bytes long.
 Data: <|               > 7C CC 0F 10 00 CD CD CD 20 B0 0F 10 0F 00 00
00 
{127} normal block at 0x011067A8, 80 bytes long.
 Data: <                > A4 C7 0F 10 00 CD CD CD 20 B0 0F 10 0B 01 00
00 
{113} normal block at 0x01105DE0, 40 bytes long.
 Data: <                > 84 B0 0F 10 00 CD CD CD 20 B0 0F 10 01 00 00
00 
Object dump complete.
___________________________________________
Andrew J. P. Maclean
Postal:
Australian Centre for Field Robotics
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Room:
106
Phone:
+61 2 9351 3283
Fax:
+61 2 9351 7474

http://www.acfr.usyd.edu.au/
___________________________________________


-----Original Message-----
From: Sebastien BARRE [mailto:sebastien.barre at kitware.com] 
Sent: Wednesday, 12 December 2001 09:38
To: a.maclean at acfr.usyd.edu.au
Cc: 'Joco Filipe de Castro Ferreira'; 'Lista do VTK'
Subject: Re: [vtkusers] RE:Comment on: *The solution* Re: Access
violations in MFC sample

At 12/12/2001 09:22 AM, Andrew J. P. Maclean wrote:
>This is strange. In int vtkMFCRenderView::OnCreate(LPCREATESTRUCT
>lpCreateStruct)
>I have:
>{
>   if (vtkMFCView::OnCreate(lpCreateStruct) == -1)
>     return -1;
>
>   // TODO: Add your specialized creation code here
>   this->RenderWindow->SetParentId(lpCreateStruct->hwndParent);
>   this->RenderWindow->SetWindowId(this->m_hWnd);
>   this->RenderWindow->WindowInitialize();
>   return 0;
>}
>
>The key is to call vtkMFCView::OnCreate(...) before setting the
>Parent/Window ID and then initializing.

I do not see any difference between this code and the current CVS code.

>As I said, I have no access violations at all with the above paradigm.
>After checking with the debugger, everything seems to be initialized
and
>allocated correctly.

Build -> Start Debug -> Go
then exit the example

Look at the debug win:
Detected memory leaks!
Dumping objects ->
{713} normal block at 0x07291BC8, 15 bytes long.
  Data: <vtkOpenGLLight > 76 74 6B 4F 70 65 6E 47 4C 4C 69 67 68 74 00
{712} normal block at 0x07291888, 12 bytes long.


--
Sebastien Barre