# OpenGL glClear causes process to not close!

This topic is 3078 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Having the line glClear( GL_COLOR_BUFFER_BIT ) in my function update_screen, causes the process not to be able to exit! It worked fine, before, but my laptop bricked, i got a new one, and now on this new laptop, on Fedora (Linux) 13, i get this error. Fedora 13 is in alpha stages, so this very well could be an OS problem, especially since the code worked before. But before i was working on Fedora 12, so it also feels unlikely. The fallowing is my main.cpp with every line that could be deleted is deleted while still producing the problem.
#include "ScopeGuard.h"

#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>

// FUNCTIONS //
GLenum init_gl( int w, int h )
{
glClearColor( 0.0f, 0.0f, 0.0f, 0.0f );

glMatrixMode( GL_PROJECTION );
glOrtho( 0, w, h, 0, -1, 1 );

glMatrixMode( GL_MODELVIEW );

return glGetError();
}

bool make_sdl_gl_window( int w, int h )
{
if( ! SDL_SetVideoMode(w, h, 32, SDL_OPENGL) )
return false;
init_gl( w, h );
return true;
}

void update_screen()
{
glClear( GL_COLOR_BUFFER_BIT );
}

int main()
{
// Portably suppresses unused variable compiler warnings.
#define NOT_USED(var) ((void)(var))

bool quit = false;
SDL_Event event;

if( SDL_Init( SDL_INIT_EVERYTHING ) < 0 )
return 1;
make_sdl_gl_window( 1200, 800 );
ScopeGuard quitSdl = scope_guard( SDL_Quit ); NOT_USED( quitSdl );

while( quit == false )
{
while( SDL_PollEvent( &event ) )
{
if( event.type == SDL_QUIT )
quit = true;
}

Uint8* keyState = SDL_GetKeyState( 0 );
if( keyState[SDLK_ESCAPE] )
quit = true;

update_screen();
}
}

If you're not familiar with Scope guard, check this out. What happens is the window appears. I hit esc (or click the X). The process' status goes to "sleeping". I go into System Monitor and "end process" and the window closes. Compiler information:
$g++ -o run -Wall -lGL -lSDL main.cpp$ g++ -v
Using built-in specs.
Target: i686-redhat-linux
Configured with: ...
gcc version 4.4.3 20100409 (Red Hat 4.4.3-16) (GCC)
EDIT: Removed the info in Configured with: since it made the post's width unbearable.

##### Share on other sites
You forgot the most important thing, the GL implementation. Mesa? NVIDIA's? ATI fglrx?

But anyway, that is clearly a driver bug.

##### Share on other sites
I'm not an SDL user so I don't know the function name, but you don't seem to be presenting the back-buffer to the screen at any point.
Perhaps if you flip the buffers then the driver won't hang.

The function name might be: SDL_GL_SwapBuffers
[edit2]Alternatively, try calling glFinish before exiting, to let the driver know that you're waiting on it.

##### Share on other sites
Quote:
 Original post by HuntsManYou forgot the most important thing, the GL implementation. Mesa? NVIDIA's? ATI fglrx?

Mesa. I could not get drivers installed for my graphics card, so i'm using that. (I was told driver implementations included openGL implementations.)

Quote:
 Original post by HodgmanI'm not an SDL user so I don't know the function name, but you don't seem to be presenting the back-buffer to the screen at any point.

Correct. The error occurred with or without that line, so i deleted it to narrow down my focus.

##### Share on other sites
Have you tried connecting a gdb to the process after hitting ESC?

You say "gdb -p <process_id>". The debugger will attach and will halt the process and put up a command prompt.

"where" will show where the process is; it'll be a list of locations; hopefully one of them will tell you where it's waiting. If they're not useful, add "-ggdb" to your compile and link commands (it puts in extra information for the debugger).

"cont" will set the process running again. Ctrl-c will then drop the process back to the gdb command line so you can do more investigation.

"quit" will exit gdb.

'that is clearly a driver bug'

It seems a little early to be presuming that. If glClear() didn't work, a fairly large number of people are likely to noticed before now. I'm not saying the drivers don't have any bugs, but here is Katie's Beginner Programmer Rule Number One; "your code is the least tested part of whatever system you are trying to build and hence you should suspect that first and for quite a long time".

##### Share on other sites
Adding glFlush to the end of my program worked!

1. 1
2. 2
3. 3
Rutin
22
4. 4
frob
16
5. 5

• 9
• 33
• 13
• 12
• 10
• ### Forum Statistics

• Total Topics
632575
• Total Posts
3007154

×