On Wed, Jan 13, 2010 at 04:07:24PM -0500, Tom Lane 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
On Wed, Jan 13, 2010 at 04:54:34PM -0500, Simo Sorce wrote:
On Wed, 13 Jan 2010 22:39:43 +0100
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
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
Heya!
if you have code that links against libxml2 and calls
xmlCleanupParser() please verify that your project does that at the
appropriate place (i.e. immediately before exiting, and only once).
That function might delete TLS fields that belong to other libraries
(such as PA's client libs) if
Lennart Poettering mzerq...@0pointer.de writes:
if you have code that links against libxml2 and calls
xmlCleanupParser() please verify that your project does that at the
appropriate place (i.e. immediately before exiting, and only once).
Why exactly is this a misuse, and not libxml2's bug to
On Tue, 12.01.10 20:07, Tom Lane (t...@redhat.com) wrote:
Lennart Poettering mzerq...@0pointer.de writes:
if you have code that links against libxml2 and calls
xmlCleanupParser() please verify that your project does that at the
appropriate place (i.e. immediately before exiting, and only
