Re: [xml] xmlParserCtxt Leak?

On Mon, Jun 16, 2008 at 09:16:20AM -0700, mt2 wrote:
I implemented the changes you recommended and it works; everything
seems to be in order now. I've implemented the same situation with
plain xmlInitParser() and didn't see that "still reachable" data,
which is the only reason I posted here. Now that I know that is
"per-thread data", it makes a lot more sense. Valgrind doesn't
complain anymore either, so my life is a lot happier. Thank you for
your help and information.


Daniel, thank you, too, for your help. I put the offending code in a
loop as you suggested, and when compiled against libxml with memory
debug, all turns out well. Thank you for that hint. If I need help
again, I will make to sure to do that; this is still a learning
process for me. The example I posted is exactly the same as my own
code, but I figured it would be best, though, if you didn't have to
scroll through pages of comments and such.

Is there any more information I can read about this "per-thread data"?
I'd like to learn more.

  Not very glorious, basically it shouldn't exist, but the API
included global variables allowing to change the library behaviour.
This is a big mistake, but well it's here, and to limit the damage
it's better in multithreaded applications to have per thread global
variable values, so there is a module globals.c in the library implementing
  Advice, don't try to use global variables from the library, and
avoid trying to make use of this 'feature'.


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]