On Wed, Jan 13, 2010 at 03:57:46PM -0600, Michael Cronenworth wrote:
> Daniel Veillard wrote:
> > The problem is that you can perfectly have application not relying on
> > libxml2 outside of their own code use libxml2 at different phases,
> > for example when parsing input, and when generating resu
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
On Wed, Jan 13, 2010 at 04:07:24PM -0500, Tom Lane wrote:
> Lennart Poettering 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'
On Wed, 13.01.10 16:54, Simo Sorce (sso...@redhat.com) wrote:
> > 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 xmlCleanupP
Daniel Veillard wrote:
> The problem is that you can perfectly have application not relying on
> libxml2 outside of their own code use libxml2 at different phases,
> for example when parsing input, and when generating result, not using
> the library in the meantime and calling xmlCleanupParser() tw
On Wed, 13 Jan 2010 22:39:43 +0100
Lennart Poettering wrote:
> On Wed, 13.01.10 16:07, Tom Lane (t...@redhat.com) wrote:
>
> >
> > Lennart Poettering writes:
> > > There's something else that came to my mind: if libxml2 is loaded
> > > into memory indirectly because some dlopen'ed module wante
On Wed, 13.01.10 16:07, Tom Lane (t...@redhat.com) wrote:
>
> Lennart Poettering 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 dlc
Lennart Poettering 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() f
On Wed, 13.01.10 16:00, Daniel Veillard (veill...@redhat.com) wrote:
> > Afaik it does, i agree with Lennart that a warning from libxml2 would be
> > welcome.
>
> The problem is that you can perfectly have application not relying on
> libxml2 outside of their own code use libxml2 at different p
On Wed, Jan 13, 2010 at 02:19:16AM +0100, Haïkel Guémar wrote:
> Le 13/01/2010 02:07, Tom Lane a écrit :
> >
> > Why exactly is this a misuse, and not libxml2's bug to fix? There's
> > certainly nothing in their documentation suggesting that there's
> > such a requirement.
there is definitely,
On 01/13/2010 09:07 AM, Tom Lane wrote:
> Lennart Poettering 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 mis
On Wed, 2010-01-13 at 03:54 +0100, Lennart Poettering wrote:
> Oh, and we definitely need a source code indexer for fedora too!
It's coming.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
On Wed, 13.01.10 00:21, Lennart Poettering (mzerq...@0pointer.de) wrote:
> 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
On Tue, 12.01.10 20:07, Tom Lane (t...@redhat.com) wrote:
>
> Lennart Poettering 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).
>
>
Le 13/01/2010 02:07, Tom Lane a écrit :
>
> Why exactly is this a misuse, and not libxml2's bug to fix? There's
> certainly nothing in their documentation suggesting that there's
> such a requirement.
>
> regards, tom lane
Afaik it does, i agree with Lennart that a warning
Lennart Poettering 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 fix? There's
certa
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 ca
17 matches
Mail list logo
