#20 glui->close() revisited

open
nobody
5
2014-08-24
2006-05-15
Anonymous
No

I searched the forum and found one other instance of
this problem, but no solution. The bug occurs during a
call to glui->close() and occurs on the windows
platform exclusively. This bug was uncovered as part of
work on a project in which a handful of UI pop-up
windows are necessary to support some detailed
functionality. Each popup window is in its own class,
of which an instance is created when the user wishes to
view the pop-up window. When the user has completed
work with the window and clicks the “OK” button the
window is closed using glui->close() and the parent
class is notified so it can delete the instance of the
class. This setup has been working fine just so far on
the mac, but on windows, the infinite loop lockup occurs.

As for more details on this infinite loop lockup; I’ve
spent a few days now trying fruitlessly to obtain a
solution to this one. I traced the crash down through
glui and glut all the way down to a OpenGL call. The
lock occurs in glutReportErrors (line 46 of
glut_util.c), where the following code is called:

GLenum error;

while ((error = glGetError()) != GL_NO_ERROR)
__glutWarning("GL error: %s", gluErrorString(error));

The problem that is occurring at this point is that
glGetError, or at least the nVidia build, will always
return GL_INVALID_OPERATION and will never return
GL_NO_ERROR. I have tested this in a project with
nothing but the gl.h, glu.h, and a while loop to
glGetError, and it does in fact lock.

There are two strange things about this. First,
glutReportErrors is called from the work loop only when
the __glutDebug flag is set. And from as far as I can
tell, this only occurs through using the –gldebug
command line flag. Second, it only calls
glutReprotErrors after closing the window.

If I go into the glui library and comment out
glutDestroyWindow(glutGetWindow()); in
GLUI_Main::close_internal( void ) (line 1363 of
glui.cpp) then the lock never occurs. GLUI cleans up
everything properly and I’m left with a shell of a
window like I’d expect.

Just to check glutDestroyWindow for bugs, I built a
test program that involved creating and destroying
multiple windows using glut only and no glui, this did
work successfully.

As a last ditch effort to stem this problem, I built
glut with the modified line:

ifndef _WIN32

GLenum error;

while ((error = glGetError()) != GL_NO_ERROR)
    __glutWarning("GL error: %s", gluErrorString(error));

endif

While this did stop the infinite loop, it did cause me
to get a null pointer exception upon closing a window.
The null pointer, is suspect, is the root of this bug,
but I have not had the time or patience to try to track
that down further.

Attached is a modified version of example2 which opens
and closes the side window in a similar method to the
one in our project. If you run this on a windows
system, you should see the console become spammed with
a GLUT Warning message when you hit the close button on
the side panel. (I apologies for the sloppiness of the
code, I was just trying to get something quick and
dirty working for testing).

If you need any additional information, you can contact
me at BMaisler@gmail.com.

Discussion

  • Nobody/Anonymous

    Example Program With Crash

     
  • Nobody/Anonymous

    sUBz9G zxuhhusqwpxa, [url=http://jdswtvjknqpy.com/]jdswtvjknqpy[/url], [link=http://ncscvlxkqedl.com/]ncscvlxkqedl[/link], http://zyjwcaykmjfg.com/

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2013-02-27

    Ok I have been playing with this all night. The only solution that actually seems to work is to unlink the window with glui::unlink() and then to destroy the window with GLUT.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks