Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Andy Ross wrote: Seriously: consider the case where this symbol came out of a library that we *don't* link to statically. Why would I? Then this would undeniably be a bug, because the library would be unmapped before the function could be called. Honestly, this code is just wrong. No it's not. I can't see a case where a program that relies so heavily on OpenGL wouldn't link to the GL library at link time. Let's turn this around: what do you *want* the dlclose() invocation to do for you? Its documented behavior is to close and invalidate the shared library mapping if it is currently unused. Since you are caching and returning a pointer to a function in the library, this cannot possibly be what you want. Why is the line there if we all agree it is a no-op? Occam's razor demands that you take it out. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Andy Ross wrote: Erik Hofman wrote: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I think the idea here is that dlclose() is unmapping the memory region associated with the shared library. The pointer still has the same value, but there are no page table entries associated with that address any more, so an instruction fetch from that address causes a segmentation fault. Yes there should be, dlopen/dlclose keep a counter for the number of dlopen *and dlclose calls and only removed the library when the number of dlclose calls equals the number of dlopen calls. Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. In which case the dlclose() is 100% guaranteed to be a noop anyway and can be safely removed. :) Seriously: consider the case where this symbol came out of a library that we *don't* link to statically. Then this would undeniably be a bug, because the library would be unmapped before the function could be called. Honestly, this code is just wrong. You don't close the library before calling functions in it, you just don't. Yes, the POSIX docs for dlclose() seem to imply that it should be safe as long as something else has a handle to libGL, but it's still not correct. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Alex Romosan wrote: trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Alex Romosan wrote: trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I checked the manual page for dlclose on Linux and Tru64 ( ex Digital Unix ) On Linux, it seems dlclose decrement a counter and the library is unloaded when it comes to zero. As libGL.so is already loaded by the linker, it should stay linked, except perhaps if the static link was made with libGL.a. OTOH, on Tru64, the man page says : The dlclose function deallocates the address space for the library corresponding to handle. The results are undefined if any user function continues to call a symbol resolved in the address space of a library that has since been deallocated by dlclose. So, if the library is really unloaded, the pointer access should be really undefined and could lead to a segfault. Anyway, is it really mandatory to do dlclose after getting the pointer ? It is if we do dlopen every time we get a pointer, but the handle could be allocated only once and stored for subsequent lookup. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I think the idea here is that dlclose() is unmapping the memory region associated with the shared library. The pointer still has the same value, but there are no page table entries associated with that address any more, so an instruction fetch from that address causes a segmentation fault. The meaning of dlclose() is I don't need this library any more, not please close the handle, I have what I need. Alex is right, this is a bug, even if it doesn't cause crashes up on all platforms. We clearly don't want to unload the OpenGL library. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
