[vtkusers] VTK+Java Crash while rendering

Jeff Lee jeff at cdnorthamerica.com
Tue Oct 28 07:44:36 EST 2003


see below,

Shyam Prakash wrote:

>Jeff,
>	I completely agree with your reasoning. It is possible that a
>paint call is generated while my underlying data is being changed. 
>
>  
>
>>>	One way to stop the problem is 
>>>	to mutex while changing the data and also use the same mutex
>>>      
>>>
>when 
>  
>
>>>	rendering.  Basically, both actions require the same lock and so
>>>      
>>>
>
>  
>
>>>	cannot conflict.  This should prevent a render while the data is
>>>      
>>>
>
>  
>
>>>	changing.
>>>      
>>>
>
>Do you mean the Lock/UnLock methods of vtkPanel? 
>  
>
no, i mean a real mutex, i.e. one from doug lea's concurrent lib, or 
even a simple globally-accessible Object lock.  Lock/UnLock do not know 
anything about what you are doing with the data, they just mutex the 
drawing surface.  anyway, the basic idea is to check out the mutex when 
rendering, and have that mutex accessible to the class which is changing 
the data.  in a render-centric world, the data-changer-guy would have to 
grab the mutex from the renderer-guy before being able to change the 
data.  if the renderer-guy is busy, back off and update the data later.  
in a data-changer-centric world, the opposite.  make sense?  vtk is a 
non-thread-safe toolkit.  this is one of those things that cannot be 
built into vtkPanel, but must be built into your system.
Jeff

>Thanks
>Shyam
>
>
>-----Original Message-----
>From: Jeff Lee [mailto:jeff at cdnorthamerica.com] 
>Sent: Tuesday, October 28, 2003 5:27 PM
>To: Shyam Prakash
>Cc: 'vtkusers'
>Subject: Re: [vtkusers] VTK+Java Crash while rendering
>
>If you try to render while the underlying data is changing, it is still 
>possible to get this type of behavior.  One way to stop the problem is 
>to mutex while changing the data and also use the same mutex when 
>rendering.  Basically, both actions require the same lock and so cannot 
>conflict.  This should prevent a render while the data is changing.
>-Jeff
>
>Shyam Prakash wrote:
>
>  
>
>>Hi,
>>
>>            I have been facing this problem for quite some time. I am 
>>developing an application using vtk 4.2.2 and jdk 1.4.1_02 on windows.
>>
>>The tool crashes some time with the following error message. However 
>>this crash is not reproducible. This always happens in the JVM 
>>generated paint() method call. Is there a workaround to stop this
>>    
>>
>crash?
>  
>
>> 
>>
>>An unexpected exception has been detected in native code outside the
>>    
>>
>VM.
>  
>
>>Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at
>>    
>>
>PC=0x27123331
>  
>
>>Function=vtkFileOutputWindow::NewInstance+0x1A906
>>
>>Library=C:\WINNT\System32\vtkCommon.dll
>>
>> 
>>
>>Current Java thread:
>>
>>            at vtk.vtkRenderWindow.Render_6(Native Method)
>>
>>            at vtk.vtkRenderWindow.Render(vtkRenderWindow.java:36)
>>
>>            at vtk.vtkPanel.Render(vtkPanel.java:137)
>>
>>            - locked <056CA5D8> (a com.gui.Viewer)
>>
>>            at vtk.vtkPanel.paint(vtkPanel.java:151)
>>
>>            at sun.awt.RepaintArea.paint(Unknown Source)
>>
>>            at sun.awt.windows.WComponentPeer.handleEvent(Unknown
>>    
>>
>Source)
>  
>
>>            at java.awt.Component.dispatchEventImpl(Unknown Source)
>>
>>            at java.awt.Component.dispatchEvent(Unknown Source)
>>
>>            at java.awt.EventQueue.dispatchEvent(Unknown Source)
>>
>>            at 
>>java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
>>
>>            at 
>>java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
>>
>>            at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>
>>            at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>>
>>            at java.awt.EventDispatchThread.run(Unknown Source)
>>
>> 
>>
>>Thanks and Regards
>>
>>Shyam
>>
>> 
>>    
>>





More information about the vtkusers mailing list