[vtkusers] Serious(?) flaws in vtk code

[William A. Hoffman]

Where is Project_vtkDemo?  Can it be fixed so other people
do not run into this problem?

-Bill


At 12:32 PM 3/9/2004, Xianjin Yang wrote:

>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>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>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 
>>