[vtkusers] Serious(?) flaws in vtk code

[Xianjin Yang]

Dear all,

I have been using BCB6 + VTK 4.2 and had similar problems before.
To solve Access violation problem related to DummyCritSect.Lock() in the
destructor of vtkPolyData (~vtkPolyData), I did these in the
Project_vtkDemo:

1) Remove everything in the FormDestroy event handler.
2) Add this FormClose event handler. All problems should be gone!!

void __fastcall TVTK_Form::FormClose(TObject *Sender, TCloseAction &Action)
{
  if (shrink) shrink->Delete();
  vtkTimerLog::DeallocateTimerLog();
  vtkWindow1->GetRenderer()->RemoveAllProps();
  // VTK_Form->Release();
  // Application->Terminate();
}
I am not sure if the last two lines of code are required in BCB6.

vtkTimerLog::DeallocateTimerLog() is a fix discussed here:
http://public.kitware.com/pipermail/vtkusers/2003-August/019522.html


Xianjin Yang, Ph.D.




-----Original Message-----
From: William A. Hoffman [mailto:billlist at nycap.rr.com] 
Sent: Tuesday, March 09, 2004 10:18 AM
To: Per Dalgas Jakobsen; vtkusers at vtk.org
Subject: Re: [vtkusers] Serious(?) flaws in vtk code


I have not looked at the BCB Windows code, however,
it seems that you might be able to move the creation/destruction
of the vtk objects to a different spot.   There must be some method
that is called to initialize the BCB objects, and another one
to destroy them.   You could go to some sort of lazy create if
there is no such method.   Basically, the first time the vtk object
is used, then create the vtk object.  Then when your window gets the close
event, destroy the vtk object, don't just create and destroy the vtk objects
in the constructor/destructor of the BCB object. All vtk objects should be
created after main, and deleted before the end of main, and you should have
no problem.

-Bill


At 04:19 AM 3/9/2004, Per Dalgas Jakobsen wrote:
>Hi all,
>
>I believe I have found some flaws in the vtk code.
>I think most vtk users are not affected, but us poor souls that are 
>forced to use Borland C++ Builder (BCB) are affected.

>The problem reveals itself the following way (in my case at least): 
>Access violation in the destructor of vtkPolyData (~vtkPolyData) - The 
>DummyCritSect.Lock() call fails.
>
>The cause is that DummyCritSect, in certain cases, has already been 
>destroyed. In other words: ~vtkPolyData is calling a method in an 
>object that is no longer in existence.
>
>Explanation:
>DummyCritSect is a "nonlocal" object which is created before main() is 
>executed, and destroyed after main() has returned. This is actually 
>what is intended, and quite nice, except when used from within (but not 
>exclusively) BCB...
>
>The problem is that the Visual Component Library (VCL), which is the 
>foundation of BCB, also seems to be created from a "nonlocal" object. 
>This means that BCB Windows and DummyCritSect are created at the same 
>point, and destroyed at the same point, but the sequence is undefined.
>
>According to "The C++ Programming Language" by Bjarne Stroustrup:
>-------
>Section 10.4.9 Nonlocal store:
>
>1) "A variable defined outside any function (that is, global, 
>namespace, and class static variables; §C.9) is initialized 
>(constructed) before main() is invoked, and any such variable that has 
>been constructed will have its destructor invoked after exit from 
>main()."
>
>2) "No implementation-independent guarantees are made about the order 
>of construction of nonlocal objects in different compilation units."
>
>3) "The order of destruction is similarly implementation-dependent."
>-------
>
>This means that IF vtk is accessed from a "nonlocal" object, it is 
>implementation-dependent wether it works or not. In case of BCB, it 
>doesn't :-(
>
>As long as you are not making components containing vtk-code in BCB, it 
>is possible to make workarounds, but it seems to be impossible to get 
>component-wrapped vtk-code to work correctly.
>
>
>How do we get around this problem?
>I don't think that we should "#ifdef __BORLANDC__" our way out of the 
>BCB problem, this will leave the code flawed for projects using 
>nonlocal objects. Any thoughts?
>
>
>Best regards
>Per
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20040309/1b56c2f9/attachment.htm>