OpenGL - Segmentation Fault Problems

Scott_Lanham · February 9, 2004, 7:40pm

Hi,

I need help, my code that once worked is no longer

The problem with nvidia drivers and pthreads seems to be documented everywhere
but no matter what I do I can’t get the nvidia drivers ( both 4496 and 5336 )
to work with SDL 1.2.6. The very first gl related call and my program seg
faults. I installed Mesa, and it works fine ( but slow ).

The strange thing is that until recently I was using a gcc 2.95.4 based
unstable Debian with a locally compiled libSDL and it worked. Now I am using
Arch Linux with libc 2.3.2 and gcc 3.3.

Any help is very, very appreciated.

Thanks,

Scott.

Tyler_Montbriand · February 9, 2004, 8:00pm

Hi,

I need help, my code that once worked is no longer

The problem with nvidia drivers and pthreads seems to be documented
everywhere but no matter what I do I can’t get the nvidia drivers ( both
4496 and 5336 ) to work with SDL 1.2.6.
I wouldn’t reccomend the 5336 drivers, myself. They’re outright unstable on
my system.

The very first gl related call and
my program seg faults. I installed Mesa, and it works fine ( but slow ).
Processor, card, kernel, minimal source code example that reproduces the
problem?

Also, I might suggest trying gdb(the Gnu Debugger), it could tell you at least
WHERE it’s crashing precisely.

i.e.

$ gdb ./a.out
(inside gdb)
) run
Program a.out has segfaulted
) bt
Program a.out caused a segmentation fault in this_system_function() yada yada
) quit
Program is running, are you sure you want to exit?
) yes

$

The strange thing is that until recently I was using a gcc 2.95.4 based
unstable Debian with a locally compiled libSDL and it worked. Now I am
using Arch Linux with libc 2.3.2 and gcc 3.3.

gcc 3.3? Sounds very new to me, is that stable? What compiler options are
you using, if any?On Monday 09 February 2004 21:39, Scott Lanham wrote:

Scott_Lanham · February 9, 2004, 10:39pm

Hi Tyler,

Thanks for taking the time to help

Processor, card, kernel, minimal source code example that reproduces the
problem?

Processor: P4 2.4 Ghz 533FSB
Video: Nvidia FX5200
Kernel: 2.4.24

I have tried to put a simple code example together, but it works. It doesn’t
use the SDL thread facilities like my main program does. I will have to keep
on trying.

Also, I might suggest trying gdb(the Gnu Debugger), it could tell you at
least WHERE it’s crashing precisely.

It crashes on the first OpenGL call, specifically glClearColor(). The gdb
output as you have suggested is:

#0 0x4013d87e in glClearColor () from /usr/lib/libGL.so.1
#1 0x08051e43 in vRenderContext::clear() (this=0x80d7498) at
vRenderContext.cpp:170
#2 0x0805ba84 in vView::renderScene() (this=0x80d7560) at vView.cpp:221
#3 0x0805b905 in vView::thread() (this=0x80d7560) at vView.cpp:170
#4 0x08059160 in threadEntry(void*) (object=0x80d7560) at vThread.cpp:59
#5 0x40067fab in SDL_RunThread (data=0x80da4b8) at SDL_thread.c:218
#6 0x400681bf in RunThread (data=0x0) at SDL_systhread.c:82
#7 0x4009fcd0 in pthread_start_thread () from /lib/libpthread.so.0

Which is the same ouptut I was seeing in kdbg.

The strange thing is that until recently I was using a gcc 2.95.4 based
unstable Debian with a locally compiled libSDL and it worked. Now I am
using Arch Linux with libc 2.3.2 and gcc 3.3.

gcc 3.3? Sounds very new to me, is that stable? What compiler options are
you using, if any?

The final linking line is:

g++ -Wall -g -I/usr/include/SDL -D_REENTRANT -L/usr/lib -Wl,-rpath,/usr/lib
-lSDL -lpthread -lGL -lSNL

SNL is my own NURBS library and only uses the standard c++ libs.

Nvidia’s readme file that comes with the driver says there is a known issue
with their libGL if pthread is used under certain circumstances:

o Interaction with pthreads
Single threaded applications that dlopen() NVIDIA’s libGL
library, and then dlopen() any other library that is linked
against pthreads will crash in NVIDIA’s libGL library. This does
not happen in NVIDIA’s new ELF TLS OpenGL libraries (please see
(app-c) APPENDIX C: INSTALLED COMPONENTS for a description of
the ELF TLS OpenGL libraries). Possible work arounds for this
problem are:

        1) Load the library that is linked with pthreads before
           loading libGL.so.
        2) Link the application with pthreads.

Do you think there is something in this?

Thanks for your time,

Scott.

Scott_Lanham · February 10, 2004, 1:11am

Hi,

Here is some code that causes a seg fault.

Am I being naive in thinking that OpenGL rendering can be done in a seperate thread?

Thanks,

Scott.

#include <SDL/SDL.h>
#include “SDL_thread.h”
#include <GL/gl.h>

int thread ( void* data )
{
glClearColor ( 0.0, 0.0, 0.0, 0.0 );
return true;
}

int main()
{

SDL_Init ( SDL_INIT_VIDEO );

SDL_GL_SetAttribute ( SDL_GL_RED_SIZE, 5 );

SDL_GL_SetAttribute ( SDL_GL_GREEN_SIZE, 5 );

SDL_GL_SetAttribute ( SDL_GL_BLUE_SIZE, 5 );

SDL_GL_SetAttribute ( SDL_GL_DEPTH_SIZE, 5 );

SDL_GL_SetAttribute ( SDL_GL_DOUBLEBUFFER, true );

SDL_SetVideoMode ( 640, 480, 0, SDL_OPENGL | SDL_RESIZABLE );

glClearColor ( 0.0, 0.0, 0.0, 0.0 );

SDL_InitSubSystem ( SDL_INIT_EVENTTHREAD );

SDL_CreateThread ( &thread, 0 );

SDL_Event   event;

	bool exit = false;

	while ( ! exit )
{
	if ( SDL_PollEvent ( &event ) )
	{
		switch ( event.type )
		{
			case SDL_KEYDOWN:
				exit = true;
				break;

			case SDL_QUIT:
				exit = true;
				break;     
		}
	}
}

SDL_Quit();

}

Scott_Lanham · February 10, 2004, 2:20am

Am I being naive in thinking that OpenGL rendering can be done in a
seperate thread?

To answer my own question. It appears I can use seperate threads for rendering
but have to be able to invoke the SDL equivalent of glXMakeCurrent in each
additional thread.

Does anyone know if there is such an equivalent?

Thanks,

Scott.

Johannes_Schmidt · February 10, 2004, 2:34am

Yep. In general, all drawing should be done in the main thread.
http://www.libsdl.org/faq.php?action=listentries&category=2#61

If you really want to do your OpenGL based drawing in a separate thread, you
can use platform dependent functions (GLX) to make your GL context the
current context in that thread (glXGetCurrentContext, glXGetCurrentDrawable,
SDL_GetWMInfo, glXMakeCurrent).

Regards,
Johannes

< http://libufo.sourceforge.net >Am Dienstag 10 Februar 2004 10:10 schrieb Scott Lanham:

Am I being naive in thinking that OpenGL rendering can be done in a
seperate thread?

Couannette · February 10, 2004, 2:49am

A clever application design implies: use opengl in only ONE thread !
If you want to complicate your life continue this way

Threads are for the Ugly

Scott Lanham wrote:>>Am I being naive in thinking that OpenGL rendering can be done in a

seperate thread?

To answer my own question. It appears I can use seperate threads for rendering
but have to be able to invoke the SDL equivalent of glXMakeCurrent in each
additional thread.

Does anyone know if there is such an equivalent?

Thanks,

Scott.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Tyler_Montbriand · February 10, 2004, 5:16am

I have heard it said that SDL does not support multithreaded video
operations… I had wondered if this meant no video in a different thread or
that I can’t try and do two video operations at the same time; apparently
it’s the former.On Tuesday 10 February 2004 03:10, Scott Lanham wrote:

Hi,

Here is some code that causes a seg fault.

Am I being naive in thinking that OpenGL rendering can be done in a
seperate thread?

Nicolai_Haehnle · February 10, 2004, 8:40am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Tuesday 10 February 2004 14:19, Tyler Montbriand wrote:

On Tuesday 10 February 2004 03:10, Scott Lanham wrote:

Hi,

Here is some code that causes a seg fault.

Am I being naive in thinking that OpenGL rendering can be done in a
seperate thread?

I have heard it said that SDL does not support multithreaded video
operations… I had wondered if this meant no video in a different thread
or that I can’t try and do two video operations at the same time;
apparently it’s the former.

If you read the other replies, you’ll see that it’s in fact the latter. You
just have to make sure that the GL context is current in the thread you’re
doing the rendering from, and you can never attempt two video operations at
the same time, at least not on the same context (which makes sense; there
would be too many races involved).
IIRC, you should also be able to render to two different contexts in two
different threads simultaneously (e.g. rendering to the screen in one
thread, rendering offscreen in another thread). At least in theory…

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAKQpgsxPozBga0lwRAo/3AJ9DQxvpGsM5ky5nQ76Drt8FTJSbugCfUDwa
+5p3Oyn3Wom+rCrtv4cNqag=
=XCd4
-----END PGP SIGNATURE-----

Jonas_Hartmann · February 10, 2004, 9:29am

anyone knows an online language and function documentation for ansi c
and ansi c++?

(like this for sdl: http://sdldoc.csn.ul.ie/ or like http://www.php.net)

i am a newbie anf if i read something like strncmp(); i have to look
into a documentation just once…

regarding sdl, just if one got some links around, i need some
introduction into layerd 2d engines, sprites, collision detection, and
so on for simple 2d scrolling space shooters and a like.

sdl is great and the first steps showed me how easy things can be :-]

xodnizel · February 11, 2004, 9:50am

A separate thread for blitting/flipping video is necessary if you don’t want
to block your main thread.

If the main thread is blocked for a variable amount of time during
blits/flips(depending on refresh rate, video card capabilities, etc.), and
you’re dynamically synthesizing audio/video data(such as in an emulator),
you’re going to have to increase the amount of sound you’re buffering, which
increases latency. With multi-threaded video, if the last video update
hasn’t completed yet and the sound buffer is running low, you can just skip
that frame update easily.On Tuesday 10 February 2004 04:48, Couannette wrote:

A clever application design implies: use opengl in only ONE thread !
If you want to complicate your life continue this way

Threads are for the Ugly

Scott Lanham wrote:

Am I being naive in thinking that OpenGL rendering can be done in a
seperate thread?

To answer my own question. It appears I can use seperate threads for
rendering but have to be able to invoke the SDL equivalent of
glXMakeCurrent in each additional thread.

Does anyone know if there is such an equivalent?

Thanks,

Scott.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl