[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Richard Harke [EMAIL PROTECTED] writes: On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote: Richard Harke [EMAIL PROTECTED] writes: In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- This is on Linux ia64 My main point was intended to be the comment which says don't use the handle after dlclose i am not using the handle after dlclose() is being called. the handle is used _before_, when it's passed at to dlsym(). i actually looked at the implementation of dlsym in glibc and what i proposed is safe as the pointer returned is resolved in the scope of the main program. remember, i noticed the crash on linux running kernel 2.6 with tls. the way we used to do it, we set the pointer outside the scope of the main program by explicitly passing libGL to dlopen. we set the pointer in this scope, but we used it in the scope of the main program _after_ we called dlclose() and unmapped libGL in that particular scope. by calling dlopen(0,...) we resolve the symbol in the scope of the main program so it is safe to use after we call dlclose(). it's not that hard. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: Andy Ross wrote: 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. 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. you are mixing static and dynamic linking. andy is talking about dynamic linking. i am not sure what you are talking about. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Alex Romosan wrote: you are mixing static and dynamic linking. andy is talking about dynamic linking. i am not sure what you are talking about. Statically linking a shared-object library only means it gets dynamically linked upon program start. There is a way to do delayed static linking, but that is only useful for programs that require a shared-object library under certain circumstances (say when a menu item is selected), but not by default. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Alex Romosan wrote:
Erik Hofman [EMAIL PROTECTED] writes:
Alex Romosan wrote:
you are mixing static and dynamic linking. andy is talking about
dynamic linking. i am not sure what you are talking about.
Statically linking a shared-object library only means it gets
dynamically linked upon program start. There is a way to do delayed
static linking, but that is only useful for programs that require a
shared-object library under certain circumstances (say when a menu
item is selected), but not by default.
a better fix, which i think will work on both linux and irix is to
call the dlopen() with a null pathname. the returned handle will then
be for the main program including the libraries linked dynamically. so
the correct version of SGLookupFunction() for unix should be (modulo
the other OSs):
inline void (*SGLookupFunction(const char *func))()
{
void *handle;
void (*fptr)();
handle = dlopen (0, RTLD_LAZY);
if (!handle) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
fptr = (void (*)()) dlsym(handle, func);
if ((error = dlerror()) != NULL) {
fprintf (stderr, %s\n, error);
exit(1);
}
dlclose(handle);
return fptr;
}
tested only on linux as i don't have access to an irix system (but the
man page at
http://www.chemie.fu-berlin.de/cgi-bin/man/sgi_irix?dlopen+3 leads me
to believe it should also work on irix). hope this helps.
The fact that you are using the function pointer *after* dlclose
is as broken as Erik's version. This is not good practise to
bet on side effects that are beyond your control.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Alex Romosan wrote: Frederic Bouvier writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine So you're just guessing. The cvs version is assured to work on any system. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: Alex Romosan wrote: Frederic Bouvier writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine So you're just guessing. The cvs version is assured to work on any system. guessing about what? the version in cvs is ugly because it never calls dlclose(). the last version i proposed assigns a pointer in the scope of the program which is guaranteed to stay same for the lifetime of the program (even after calling dlclose()). no guessing there. the irix 5.3 man page states that dlopen(0,...) is supported on irix as well so that solution is portable. i wish i still had an irix machine so i could look if RTLD_DEFAULT is defined in dlfcn.h. if it is, we can then call dlsym(RTLD_DEFAULT,func) directly. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction(patch included)
On Sunday 27 June 2004 03:28 pm, Alex Romosan wrote: Frederic Bouvier [EMAIL PROTECTED] writes: Alex Romosan wrote: Frederic Bouvier writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine So you're just guessing. The cvs version is assured to work on any system. guessing about what? the version in cvs is ugly because it never calls dlclose(). the last version i proposed assigns a pointer in the scope of the program which is guaranteed to stay same for the lifetime of the program (even after calling dlclose()). no guessing there. the irix 5.3 man page states that dlopen(0,...) is supported on irix as well so that solution is portable. i wish i still had an irix machine so i could look if RTLD_DEFAULT is defined in dlfcn.h. if it is, we can then call dlsym(RTLD_DEFAULT,func) directly. --alex-- In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Richard Harke [EMAIL PROTECTED] writes: In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction(patch included)
On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote: Richard Harke [EMAIL PROTECTED] writes: In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- This is on Linux ia64 My main point was intended to be the comment which says don't use the handle after dlclose Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Alex Romosan wrote: Erik Hofman [EMAIL PROTECTED] writes: 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 ?? dlclose() doesn't have the effect on the pointer. it just makes that pointer point to something non-existent once the handle becomes invalid, hence the core dump. Well, that's the part that I don't get. From the man pages: All objects loaded automatically as a result of invoking dlopen on the referenced object are also closed (however no object still open as a result of any dlopen command is closed until dlclose has closed the last open handle. You see, dlclose keeps a counter of the number of dlopen/dlclose calls and only removes the shared object when dlclose is called as many times as dlopen. FlightGear links directly to libGL, making the number of dlopen calls one more then the number of dlclose calls. This really is a bug in your shared library implementation, ot you have mangled your local copy of FlightGear in such a way that it's dlclosing libGL more than necessary. what you have there is bad programing practice. if you do a search for dlclose and dlsym you will see that nobody uses the pointer returned by dlsym() _after_ a call to dlclose() It's not bad programming practice. It's called knowing what you are doing. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: 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. this is wrong. the whole idea of linking against a shared library is that you load only the symbols you need. it doesn't mean the library is loaded in memory all the times (that will defeat the whole idea of shared libraries). linking against a shred library doesn't count as a dlopen(). the address the library is loaded at depends on how libc implements it. for linux, the core dump happens when one uses kernel 2.6 and tls enabled. the point is that there is no guarantee the pointer is still valid once you call dlclose(). if you want to guarantee the pointer to the function is still valid after calling dlclose() you hvae to call dlopen() on libGL yourself one more time outside the lookup function. that way the library will stay in the memory all the time (but this is still not a good solution). the only good solution is to make sure you use the pointer before calling dlclose() and that means moving it out of SGLookupFunction() (and hence getting rid of SGLookupFunction). you should also do some error checking with dlerror() for completeness. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: 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 ?? dlclose() doesn't have the effect on the pointer. it just makes that pointer point to something non-existent once the handle becomes invalid, hence the core dump. what you have there is bad programing practice. if you do a search for dlclose and dlsym you will see that nobody uses the pointer returned by dlsym() _after_ a call to dlclose() --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: 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. that was my original fix: comment out the call to dlclose(). if we keep things the way they are now, we should probably call dlopen() once, pass the handle, and at the end call dlclose(). SGLookupFunction() should just call dlsym(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Alex Romosan wrote: Frederic Bouvier writes: 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. that was my original fix: comment out the call to dlclose(). if we keep things the way they are now, we should probably call dlopen() once, pass the handle, and at the end call dlclose(). SGLookupFunction() should just call dlsym(). There is probably no problem of not doing dlclose at all. Standard process exit routine should do it for us. So we could write : static void *handle = 0; if ( !handle ) handle = dlopen(); fct = dlsym(); return fct; -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: There is probably no problem of not doing dlclose at all. Standard process exit routine should do it for us. So we could write : static void *handle = 0; if ( !handle ) handle = dlopen(); fct = dlsym(); return fct; or we can call dlopen() on libGL once somewhere at the beginning to make sure libGL stays loaded in memory even after calling dlclose(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes:
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, maybe this test program will help you understand the problem:
#include stdio.h
#include dlfcn.h
#include stdlib.h
inline void (*lookup(const char *func))()
{
void *handle;
void (*fptr)();
char *error;
handle = dlopen (libm.so, RTLD_LAZY);
if (!handle) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
fptr = (void (*)()) dlsym(handle, cos);
if ((error = dlerror()) != NULL) {
fprintf (stderr, %s\n, error);
exit(1);
}
printf (%f\n, (*((double (*)(double))fptr))(2.0));
dlclose(handle);
return fptr;
}
int main(int argc, char **argv)
{
double (*fptr)(double) = (double (*)(double)) lookup(cos);
printf (%f\n, fptr(2.0));
}
compile as such: g++ -o foo foo.c -ldl and then run ./foo. on my
machine i get:
-0.416147
Segmentation fault
the first result is printed before calling dlclose(). libm is still
loaded in memory and the pointer is valid. after we call dlclose()
fptr is still the same (it's a copy after all) but libm is now
unloaded and fptr points to never-never land, so we core dump. if you
comment out dlclose() then the second printf works as well.
does this help you understand the problem?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
