| |||||||||||||
|
| |||||||||||||
The Cairo operating systemThe Cairo operating systemPosted Jul 7, 2006 0:30 UTC (Fri) by nix (subscriber, #2304)In reply to: The Cairo operating system by oak Parent article: Cairo release 1.2.0 now available
dlclose() also interacts... interestingly with VM randomization.
I found a bug in Subversion (with --enable-dso) a while back which reduces to dlopen(), store a pointer to a function in the shared object in a data structure, dlclose(); later dlopen() again, call through the function pointer, *boom*; there's no guarantee that the dlopen() is at the same address this time, and with VM randomization it's pretty much guaranteed to be different.
Oops.
I think this would likely also kill C++ RTTI through repeatedly-dlopen()ed shared libraries, since that relies on pointer comparisons. The lesson in all this is to avoid dlclose().
(Log in to post comments)
The Cairo operating system Posted Jul 7, 2006 8:28 UTC (Fri) by xoddam (subscriber, #2322) [Link] > The lesson in all this is to avoid dlclose().... er ... or at least to invalidate any dlsym()s you have cached when you dlclose(), as any *sane* developer would, and look them up afresh if/when you re-dlopen() the library.
The Cairo operating system Posted Jul 7, 2006 10:15 UTC (Fri) by nix (subscriber, #2304) [Link] Well, yes, but it can be hard to keep track of such things if you're keeping pointers to some entities which are dlsym()ed from different places and others which are not, in the same data structure.
|
|
||||||||||||