Nvidia drivers, pthreads and segfaults

I have code that works on two different machines with intel integrated graphics. I just built a new box with the nvidia ION chipset and as such I’m using the nvidia driver. The project involves high speed video capture so I’m doing it in a thread using ofxThread and the gstreamer vidgrabber. This all works perfectly on my other two machines. Once I put it on the new one I’m now getting segfaults from within my capture thread. it runs for a bit, then once the opengl window is created it dies (i see the window flash on screen and disappear).

I’ve tried starting the capture thread after the window is created and it does not help.

I’ve search around and found this but I am unsure how to go about solving the problem for oF.

A quick google session shows the combination pthreads / dlopen/libGL.so and
nvidia/ati drivers are causing crashes with lots of games, including DOOM3
etc.

from http://dri.sourceforge.net/doc/DRIuserguide.html
"
11.5 libGL.so and dlopen()

A number of popular OpenGL applications on Linux (such as Quake3, HereticII,
Heavy Gear 2, etc) dynamically open the libGL.so library at runtime with
dlopen(), rather than linking with -lGL at compile/link time.

If dynamic loading of libGL.so is not implemented carefully, there can be a
number of serious problems. Here are the things to be careful of in your
application:

* Specify the RTLD_GLOBAL flag to dlopen(). If you don’t do this then
you’ll likely see a runtime error message complaining that _glapi_Context is
undefined when libGL.so tries to open a hardware-specific driver. Without
this flag, nested opening of dynamic libraries does not work.
* Do not close the library with dlclose() until after XCloseDisplay() has
been called. When libGL.so initializes itself it registers several callbacks
functions with Xlib. When XCloseDisplay() is called those callback functions
are called. If libGL.so has already been unloaded with dlclose() this will
cause a segmentation fault.
* Your application should link with -lpthread. On Linux, libGL.so uses
the pthreads library in order to provide thread safety. There is apparently
a bug in the dlopen()/dlclose() code which causes crashes if the library
uses pthreads but the parent application doesn’t. The only known work-around
is to link the application with -lpthread.

Some applications don’t yet incorporate these procedures and may fail. For
example, changing the graphics settings in some video games will expose this
problem. The DRI developers are working with game vendors to prevent this
problem in the future. "

I believe I am being affected by the above predicament. I am running ubuntu 9.04 64bit.
Please help! I have a show coming up soon and I was hoping to use this new machine for the installation.

hmm oF definitely links against GL at compile time so I am not sure this driver bug applies. Have you made sure your OpenGL calls are in the main thread (also check types that implicitly create a gl texture.).

Generally speaking multithreaded opengl code is not something all graphics drivers handle gracefully. More often than not your app will just crash in such cases.

Hey,

Different video cards on different machines can often turn up bugs either in your code or in the drivers. Assume it’s your code first though, because in my experience that’s often the case (but not always!). It’s a nasty territory though.

What kind of camera are you using? If it’s supports IIDC you should try the new ofxVideoGrabber addon which is also threaded. Swapping out different components of your software can sometimes isolate the problem

grimus makes a good point:

Different video cards on different machines can often turn up bugs either in your code

especially when it comes to threading, where timing and synchronization can difffer greatly on different hardware.

are you properly locking and unlocking simultaneous reads / writes on the same data? you might want to investigate commenting out certain calls, and see if they help.

also, if you are kicking off a thread and the app crashes when the window opens, maybe add an initial sleep to thread so it does nothing for a while at first.

if you are using objects in threads that have opengl specific functionality, like an object that has an ofTexture inside of it, call ofSetUseTexture(false) before allocating to disable texture use altogether for that object (otherwise, it will upload to the graphics card, etc).

hope that helps!

take care,
zach

are you sure you installed the nVidia driver correct ( i just did the same for an ION chipset on ubuntu ). did you check if other openGL apps work?
if not tr running glxgears from the terminal.

Wow what a response!

[quote author=“grimus”]Hey,

Different video cards on different machines can often turn up bugs either in your code or in the drivers. Assume it’s your code first though, because in my experience that’s often the case (but not always!). It’s a nasty territory though.

What kind of camera are you using? If it’s supports IIDC you should try the new ofxVideoGrabber addon which is also threaded. Swapping out different components of your software can sometimes isolate the problem[/quote]
Great advice, i did jump to the conclusion that it was not my code (I’m only human).
I’ll also have to check out the ofxVideoGrabber if it works with the ps3eye camera.

This sounds very promising. I am using the modified gstreamer ofVideoGrabber so i think it has the built in texture support. I will try turning it off first thing when I get to my studio tomorrow. Maybe my code will run faster as a result too.

[quote author=“moka”]are you sure you installed the nVidia driver correct ( i just did the same for an ION chipset on ubuntu ). did you check if other openGL apps work?
if not tr running glxgears from the terminal.[/quote]

Yes I’ve got compiz running and I’ve also gotten the movieGrabberExample to run. Aside from this problem, the ION platform is amazing for the work I’m doing and I imagine for other as well, I highly recommend it.

Thanks for all of your replies. I’ll let you know how it works out.

Alright, turning the texture use off fixed it. however I had to set it via the VideoGrabber.initGrabber(width,height,false) method. using videoGrabber.setUseTexture(false) did not work. Thanks a lot for the input guys!

Update:
I was able to use the new machine for the installation thanks to the oF community :slight_smile: Hopefully there will be no problems before the show starts on Friday! I’ll do some documentation at the show and post it in the examples section later.