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
