Seg-faults in GL when dynamically loading pthread
I've been working writing on some extensions for quakeforge and I've come across an interesting problem:
When I load a shared library that uses the pthread library, GL seg-faults while rendering the next frame. This only happens on GL clients with the nVidia GL library.
If the pthread library is linked in to quakeforge's GL renderer, the seg-fault does not occur. This suggests to me that the nVidia GL library is using pthread if it is present, but doesn't work cleanly with it unless it has been initialized before any GL operations begin.
Is there any way that we can deal with this problem aside from linking in pthread when using the nVidia GL library?
When you say "load a shared library", do you mean calling dlopen() on it?
There is a question in the driver README, in the FAQ section, that covers issues calling dlopen() on shared libraries (on the libGL.so specifically, but due to the problem's cause, I wouldn't be surprised if the same issue would cause problems on libpthread.so too).
> When you say "load a shared library", do you mean calling dlopen() on it?
Yes. That's exactly what I mean.
I have no problems loading any other shared libraries dynamically, only pthread, but I'll take a look at the FAQ - thanks.
From the README:
> 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.
Pretty much the work-arounds I was hoping to avoid :-/ The other option is to upgrade to GLIBC 2.3+ so that the ELF TLS libs can be used.
That's not the question I was thinking of, but yeah, that is the problem. ;)
I was thinking it was a bug in your glibc, but never mind, it's not. It's that.
Upgrading to glibc 2.3 won't necessarily help, either -- you need the end users to all have the TLS libGL installed on their systems, and that's a function of the kernel and glibc both, I think. I believe that no distros other than RH 9 need the TLS libGL (though I'm building a Linux From Scratch with glibc 2.3.2 and kernel 2.4.20 -- glibc has TLS, but the kernel won't -- to see which libs the installer uses for that kind of setup), because only RH9 uses the kernel implementation of TLS. Could be wrong, though...
We'll probably end up just putting a check in "configure": if nvidia gl and pthread is installed, link it into the GL renderer. Kinda icky, but it solves the problem.
Thanks for your help, bwkaz :-)
|All times are GMT -5. The time now is 01:26 PM.|
Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.