On Wed, 13 Jan 2010 22:39:43 +0100 Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Wed, 13.01.10 16:07, Tom Lane (t...@redhat.com) wrote: > > > > > Lennart Poettering <mzerq...@0pointer.de> writes: > > > There's something else that came to my mind: if libxml2 is loaded > > > into memory indirectly because some dlopen'ed module wanted it, > > > and then used, and then unloaded again because the module got > > > dlcose'd again, won't you leak TLS vars unless the > > > xmlCleanupParser() function was called properly before? In that > > > case, not calling xmlCleanupParser() is an error, right? And > > > calling it, too, since some other plugin/thread might still need > > > it. Which means you are in a dilemma: in either case you are > > > doing it wrong. > > > > Got it in one. libxml's API in this area is unusably broken, and > > needs a ground-up redesign not random messages telling users that > > they didn't use it right --- there *is* no right way to use it. > > Dunno. I wouldn't be so harsh. If libxml2 is linked with -z nodelete > (maybe it already is? I never checked...) this dilemma *does* go > away. And if then xmlCleanupParser() would be renamed to something > like xmlCallMeOnlyIfYouValgrindMeOtherWiseYouSuck() and then make the > symbol xmlCleanupParser() a NOP plus a gcc linker warning things are > more than fixed in my eyes. > > (Oh, and the issue above would leak memory too, not just TLS, but TLS > is usually more of a scarce resource) > > Oh, and let's note that other libraries have exactly the same > probs. Let's pick dbus for example which many might consider a > benchmark in many ways. There is dbus_shutdown() which does about the > same thing as xmlCleanupParser(). And libdbus isn't linked with -z > nodelete. A module that pulls it in has hence exactly the same > problems. For example, let's say there was a module by the name of > /lib64/security/pam_ck_connector.so which links against libdbus.so it > will leak memory each time it is invoked by a process that not by > itself links against libdbus, which we'll call "/bin/login" for > now. And there you have it: the same dilemma: either the module calls > dbus_shutdown and hence breaks every other dbus-using PAM module that > might be loaded, or it might not call it in which case it will leak > memory. Same dilemma. > > It's a common problem. In fact, libpulse had a similar issue until i > added -z nodelete to its linker line. The dilemma is in broken libraries that use global variables instead of explicitly initialized memory contexts so that you can have multiple completely independent instances and also happen to help make them thread safe. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
