[vtkusers] segfault with Opengl2 in 6.3.0.rc2

Mon Sep 14 03:46:22 EDT 2015

FYI, the problem is still present in the final VTK 6.3. The solution 
provided by Ken can be found at

https://gitlab.kitware.com/vtk/vtk/merge_requests/638

Marcin

On 09/08/2015 03:32 PM, Marcin Krotkiewski wrote:
> Hi, Ken,
>
> I have found two issues here. First, I think the vtk.sample.VTKCanvas 
> example (on which I based my simplified code) might be wrong because 
> it does not call frame.setVisible in EDT. From what I have seen in 
> other examples frame.setVisible should be called from InvokeLater. 
> Note that there are other places in Java examples where 
> JFrame.setVisible is called _NOT_ from within InvokeLater. If this is 
> an error, it might be a good idea to fix this.. At least for me 
> changing this partly fixed the problem, i.e., the error was more 
> difficult for me to get in the example, but not in my real code, where 
> frame.setVisible is called from EDT  (I am _almost_ certain of this, 
> as I call Java indirectly from MATLAB, and I do use MATLABs EDT 
> framework).
>
> Hunting the real problem, I have already mentioned that I got error 
> from glewInit. Writing out the reason for the error gave me 'Missing 
> GL version'. I am no expert in OpenGL, so I googled around and 
> understood that this might mean that glewInit was called before OpenGL 
> context was created. Due to this fact glew was not initialized and the 
> code segfaulted on call to glBlendFuncSeparate in OpenGLInitState due 
> to the address being NULL.
>
> This made me experiment with vtkOpenGLRenderWindow and 
> vtkXOpenGLRenderWindow. I have found that from 6.2 you have changed 
> the initialization in vtkXOpenGLRenderWindow::CreateAWindow. In 
> particular, you have added the if statement after '// try for 32 
> context'. Being desperate I have commented out the entire 
> if(this->internal->fbconfig)  statement. This worked for me, i.e., I 
> did not manage to get a glewInit error after the change. Neither in my 
> code, nor in the VTKCanvas sample.
>
> I do not know exactly what this code does, but it might need a second 
> look. From the observed behavior it was very much like a race 
> condition: I was getting the glewInit 'Missing GL version' condition 
> sometimes, but not always. Of course, this might mean that commenting 
> out those lines does not fix anything, just hides the problem.
>
> Let me know if you need more information - I will gladly work towards 
> fixing this.
>
> Marcin
>
>
>
> On 09/08/2015 02:47 PM, Ken Martin wrote:
>>
>> Can either of you verify that the VTK C++ tests work on the system? 
>> E.g.  ctest –R Mace passes?  Just trying to see if this is a general 
>> system/VM issue or tied specifically to Java/OpenGL2 interactions.
>>
>> Thanks
>>
>> Ken
>>
>> Ken Martin PhD
>>
>> Chairman & CFO
>>
>> Kitware Inc.
>>
>> 28 Corporate Drive
>>
>> Clifton Park NY 12065
>>
>> ken.martin at kitware.com <mailto:ken.martin at kitware.com>
>>
>> 919 869-8871 (w)
>>
>> This communication, including all attachments, contains confidential 
>> and legally privileged information, and it is intended only for the 
>> use of the addressee.  Access to this email by anyone else is 
>> unauthorized. If you are not the intended recipient, any disclosure, 
>> copying, distribution or any action taken in reliance on it is 
>> prohibited and may be unlawful. If you received this communication in 
>> error please notify us immediately and destroy the original message.  
>> Thank you.
>>
>> *From:*vtkusers [mailto:vtkusers-bounces at vtk.org 
>> <mailto:vtkusers-bounces at vtk.org>] *On Behalf Of *Jens Schmidt
>> *Sent:* Monday, September 7, 2015 12:53 PM
>> *To:* marcin.krotkiewski; VTK Users
>> *Subject:* Re: [vtkusers] segfault with Opengl2 in 6.3.0.rc2
>>
>> To chime in, the jvm (1.8.60) crashes on debian jessie (virtualbox) 
>> when using the opengl2 rendering backend (vtk 6.3.0rc1 and rc2) and 
>> the swtComponent. The old OpenGL works fine.
>> When not using virtualbox's 3d accelleration the window wont even 
>> open. When activating the 3d accelleration you get a window but as 
>> soon as you add some actors and call update it crashes (some of the 
>> time).
>> Also the jvm crashes when running everything on "real" hardware 
>> (Intel HD Graphics 4600) instead of a virtual machine.
>> Unfortunately i cannot access the logs right now (vacation) if this 
>> still is an issue after, i happily provide any logs you desire :-)
>> Just wanted to let you know, keep up the good work!
>>
>>
>> i also have segfaults with the opengl2 backend on linux (debian 
>> jessie) running on virtualbox.
>>
>> Am 05.09.2015 um 21:32 schrieb marcin.krotkiewski:
>>
>>     I keep getting segfaults when using vtk.sample.VTKCanvas with
>>     OpenGL2 backend in 6.3.0.rc2. This does not happen with 6.2.0 +
>>     OpenGL2, nor with the standard OpenGL backend. I use ubuntu 14.04
>>     and compile with gcc 4.9.2 and jdk1.8.0_60.
>>
>>     On my laptop, the segfaults are 100 reproducible with mesa
>>     library - some lines from glxinfo:
>>
>>
>>     OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
>>     OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
>>     OpenGL core profile shading language version string: 3.30
>>
>>
>>     When I use the high performance card (fglrx drivers, Radeon HD
>>     8790M) the segfaults sometimes happen, sometimes not. Lines from
>>     glxinfo:
>>
>>
>>     OpenGL vendor string: Advanced Micro Devices, Inc.
>>     OpenGL renderer string: AMD Radeon HD 8790M
>>     OpenGL core profile version string: 4.3.13374 Core Profile
>>     Context 15.20.1013
>>     OpenGL core profile shading language version string: 4.40
>>
>>
>>     I have attached a simplified java code based on VTKCanvas - In my
>>     experience this one segfaults always, both with mesa, and with
>>     Radeon drivers. I get the following line before vtk dies:
>>
>>
>>     ERROR: In
>>     /home/angainor/bergverk/vtk/VTK-6.3.0.rc2/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
>>     line 412
>>     vtkXOpenGLRenderWindow (0x7f110429aa90): GLEW could not be
>>     initialized.
>>
>>
>>     And this is the top of the stack reported by the dying Java VM
>>
>>
>>     R11=0x00007fcbd8a79840: <offset 0x72840> in
>>     /usr/lib/fglrx/libGL.so.1 at 0x00007fcbd8a07000
>>
>>     Stack: [0x00007fcbb94e4000,0x00007fcbb95e5000],
>>     sp=0x00007fcbb95e1148,  free space=1012k
>>     Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>     j  vtk.vtkRenderWindow.Render_9()V+0
>>     j  vtk.vtkRenderWindow.Render()V+1
>>     j  vtk.vtkPanel.Render()V+164
>>     j  vtk.vtkPanel.paint(Ljava/awt/Graphics;)V+1
>>
>>     [...]
>>
>>
>>     It seems that this is a problem specific to 6.3.0.rc2 with
>>     OpenGL2. I could not reproduce it for 6.2.0, nor when using
>>     OpenGL backend. Do you know any reason why this could happen? I
>>     will be happy to provide more information and help to solve this.
>>
>>     Cheers,
>>
>>     Marcin
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     Powered bywww.kitware.com <http://www.kitware.com>
>>
>>       
>>
>>     Visit other Kitware open-source projects athttp://www.kitware.com/opensource/opensource.html
>>
>>       
>>
>>     Please keep messages on-topic and check the VTK FAQ at:http://www.vtk.org/Wiki/VTK_FAQ
>>
>>       
>>
>>     Search the list archives at:http://markmail.org/search/?q=vtkusers
>>
>>       
>>
>>     Follow this link to subscribe/unsubscribe:
>>
>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150914/bb2c1765/attachment.html>