[vtkusers] vtkOpenGLClearErrorMacro() never returns

Robert Maynard robert.maynard at kitware.com
Wed Apr 16 09:11:53 EDT 2014


That is to silence compiler warnings about a variable that isn't being used.


On Wed, Apr 16, 2014 at 5:11 AM, Marco Sambin <m.sambin at gmail.com> wrote:

> Hi Bill,
>
> due to the fact my code significantly changed w.r.t. when I encountered
> that issue, as of now I am unable to exactly reproduce the same usage case
> as when I originally obtained that issue.
> Nevertheless, I assembled a more "isolated" test using this macro, and I
> think it is working fine now for me.
>
> Just a question: what's the purpose of the code line:
>
> [...]
> (void) maxErrors;
> [...]
>
> inside the body of the vtkClearOpenGLErrors macro, in case the VTK_REPORT_OPENGL_ERRORS
> symbol is not defined?
>
> Thanks again for your time and the patch.
> In the near future, I will probably introduce more changes in my code, and
> I will be able to test the patch more throughly. But I am sure it will work.
>
> Best regards,
>
> Marco Sambin
>
>
> On Tue, Apr 15, 2014 at 7:54 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:
>
>> Richard and Marco,
>>
>> If you can verify this patch solves your problem, I'll merge it.
>>
>> Thanks,
>>
>> Bill
>>
>>
>> On Tue, Apr 15, 2014 at 11:35 AM, Bill Lorensen <bill.lorensen at gmail.com>wrote:
>>
>>> Here is a patch; http://review.source.kitware.com/#/c/15149/
>>>
>>> Bill
>>>
>>>
>>>
>>> On Tue, Apr 15, 2014 at 11:31 AM, Bill Lorensen <bill.lorensen at gmail.com
>>> > wrote:
>>>
>>>> I see 16 is already used as a limit in some other calls, so I'll make
>>>> that the default.
>>>>
>>>>
>>>>
>>>> On Tue, Apr 15, 2014 at 11:07 AM, Aashish Chaudhary <
>>>> aashish.chaudhary at kitware.com> wrote:
>>>>
>>>>> IMO, a number of 10 should be reasonable. glGetError call is an
>>>>> expensive call and if that's happening at the exit, that may be Ok but not
>>>>> while the application is active.
>>>>>
>>>>> Also, typically you run into 2-3 error codes (at least my experience).
>>>>> It would be nice if this could be an option that you can pass to the macro.
>>>>>
>>>>> Just my thoughts.
>>>>>
>>>>> -Aashish
>>>>>
>>>>>
>>>>>
>>>>>  On Tue, Apr 15, 2014 at 10:57 AM, Bill Lorensen <
>>>>> bill.lorensen at gmail.com> wrote:
>>>>>
>>>>>> Hmmm. I can put a limit on the number of times the while loops
>>>>>> execute, but I'm not sure what that limit should be. There are many
>>>>>> possible gl errors (and glu errors)
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 15, 2014 at 8:59 AM, Marco Sambin <m.sambin at gmail.com>wrote:
>>>>>>
>>>>>>> Great Bill,
>>>>>>>
>>>>>>> thanks for your comments and thank you in advance for the patch.
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Marco
>>>>>>>  Il 15/apr/2014 14:42 "Bill Lorensen" <bill.lorensen at gmail.com> ha
>>>>>>> scritto:
>>>>>>>
>>>>>>>  It seems risky to have glGetError in a while loop without a guard
>>>>>>>> to stop the loop. According to the open GL Super Bible, the safe way to
>>>>>>>> clear the error is:
>>>>>>>> GLenum glError;
>>>>>>>> unsigned int i = 0;
>>>>>>>>   do
>>>>>>>>     {
>>>>>>>>     glError = glGetError();
>>>>>>>>     ++i;
>>>>>>>>     }
>>>>>>>>   while(i < 6 && glError != GL_NO_ERROR);
>>>>>>>>
>>>>>>>> I have see some docs that say there can be more  error codes.
>>>>>>>> Certainly, some upper bound should be set.
>>>>>>>>
>>>>>>>> I'll prepare a patch.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 15, 2014 at 5:58 AM, Richard Whitehead <
>>>>>>>> richard.whitehead at vivosight.com> wrote:
>>>>>>>>
>>>>>>>>> Marco,
>>>>>>>>> Thanks for the support!  I only get it on one of my computers,
>>>>>>>>> where OpenGL is issuing warnings, but then the purpose of this code is to
>>>>>>>>> clear warnings...  It simply doesn't work.  Hopefully someone who knows
>>>>>>>>> what it's doing could fix it.
>>>>>>>>> Thanks again,
>>>>>>>>> Richard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 15 April 2014 10:49, Marco Sambin <m.sambin at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Richard,
>>>>>>>>>>
>>>>>>>>>> quite a while ago, while I was making experiments with the use of
>>>>>>>>>> JOGL with VTK under Windows, I encountered the same issue that you describe.
>>>>>>>>>>
>>>>>>>>>> Basically, in some cases my application got stuck, and the CPU
>>>>>>>>>> usage went up to 25% (I have a quad core processor on my dev PC). I
>>>>>>>>>> discovered this was due to a "vtkClearOpenGLErrors()" call in the rendering
>>>>>>>>>> pipeline, which was iterating indefinitely in its "while" loop. Not sure
>>>>>>>>>> what was the real cause of this, did not have the time to debug in detail.
>>>>>>>>>> At that time, I worked around the problem by setting
>>>>>>>>>> the VTK_REPORT_OPENGL_ERRORS option to "false" on CMake (which forces the
>>>>>>>>>> implementation of vtkClearOpenGLErrors() to be empty). I understand that
>>>>>>>>>> this may not be a viable workaround in your case, and I also believe it
>>>>>>>>>> would be good to understand the real cause for this infinite loop inside
>>>>>>>>>> vtkClearOpenGLErrors().
>>>>>>>>>>
>>>>>>>>>> But for now, I can only let you know that "you are not alone" ;-)
>>>>>>>>>>
>>>>>>>>>> Maybe someone else on the list can shed some more light or share
>>>>>>>>>> some experience about this issue.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Marco
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 14, 2014 at 1:04 PM, Richard Whitehead <
>>>>>>>>>> richard.whitehead at vivosight.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This new macro was introduced in 6.1.0.  It is getting called
>>>>>>>>>>> when my app exits and it sits in an infinite loop.
>>>>>>>>>>> The documentation say is t is supposed to silently clear errors,
>>>>>>>>>>> but it is not doing this.
>>>>>>>>>>>
>>>>>>>>>>> Please can anyone suggest how to fix it?  Since my app is
>>>>>>>>>>> closing I am willing to discard errors, but the only method I can see that
>>>>>>>>>>> should clear errors is, well, vtkOpenGLClearErrorMacro...
>>>>>>>>>>>
>>>>>>>>>>> Many thanks,
>>>>>>>>>>>
>>>>>>>>>>> Richard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Richard Whitehead *–* Senior Imaging Engineer
>>>>>>>>>>>
>>>>>>>>>>> *Michelson Diagnostics Ltd*
>>>>>>>>>>>
>>>>>>>>>>> *M:* +44 (0)7905 955276   *T:* +44 (0)20 8308 1695
>>>>>>>>>>>
>>>>>>>>>>> *E: *richard.whitehead at vivosight.com   *W:* www.vivosight.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <http://www.vivosight.com/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Michelson Diagnostics Ltd, 1 Grays Farm Production Village,
>>>>>>>>>>> Grays Farm Road, Orpington, Kent  BR5 3BD, UK
>>>>>>>>>>>
>>>>>>>>>>> Registered Office: 3 Shearwater, Maidstone, ME16
>>>>>>>>>>> 0DW.     Registered in England No. 5732681
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>
>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>
>>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>>>
>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Richard Whitehead *–* Senior Imaging Engineer
>>>>>>>>>
>>>>>>>>> *Michelson Diagnostics Ltd*
>>>>>>>>>
>>>>>>>>> *M:* +44 (0)7905 955276   *T:* +44 (0)20 8308 1695
>>>>>>>>>
>>>>>>>>> *E: *richard.whitehead at vivosight.com   *W:* www.vivosight.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <http://www.vivosight.com/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Michelson Diagnostics Ltd, 1 Grays Farm Production Village, Grays
>>>>>>>>> Farm Road, Orpington, Kent  BR5 3BD, UK
>>>>>>>>>
>>>>>>>>> Registered Office: 3 Shearwater, Maidstone, ME16
>>>>>>>>> 0DW.     Registered in England No. 5732681
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> | Aashish Chaudhary
>>>>> | R&D Engineer
>>>>> | Kitware Inc.
>>>>> | www.kitware.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140416/c60a3806/attachment.html>


More information about the vtkusers mailing list