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

Re: [xml] Python bindings: per parser context error handlers



On Tue, Jan 14, 2003 at 10:47:28AM +0100, Stéphane Bidoul wrote:
> > > Anything specific I should check?
> > 
> >   Hum, all entry points which may generate such a parser context wrapper
> > object and similary anything which may destroy one. Nothing specific in
> > mind, but for example a reader instance embed a parser context at the
> > C level and while there is no API to export it that may be added at some
> > point, it seems your suggestion would cover this fine, but taht need checking.
> 
> This is only remotely related but
> I've noticed that htmlFreeParserCtxt is exposed.
> That may cause some troubles because the free
> is already done in parserCtxt.__del__.
> 
> > > Ok. That will be later this week.
> 
> Here it is, with a test case.
> 
> A few things worth noting:
> - xmlFreeParserCtxt is not autogenerated anymore
>   because it needs to free _private (added to libxml.c,
>   and to generator.py:skip_function). This has the side
>   effect that parserCtxt.freeParserCtxt is not there
>   anymore; it can be readded, but I fear a double free
>   problem, like for htmlFreeParserCtxt above.
> - initialization of _private is done in libxml_xmlParserCtxtPtrWrap.
> - I've added a parserCtxtCore base class to parserCtxt
>   to hold registerErrorHandler and registerWarningHandler
>   (because I could not find a way to autogenerate them).
> - I've factored out a libxml_buildMessage from 
>   libxml_xmlErrorFuncHandler.

  It applies cleanly, it looks sound overall, but it generate memory
leaks which are exposed by the existing regression tests. Anything
using the external entity loader seems to leak the python C object
wrapper allocated in libxml_xmlParserCtxtPtrWrap() 
  The new code seems to miss one of the Python reference counting
decrement which were present in the previous code.
  Stack trace for running tests/reader3.py where the leaked block
is allocated:

#2  0x400f145c in xmlMemMalloc (size=16) at xmlmemory.c:220
#3  0x40094f0b in libxml_xmlParserCtxtPtrWrap (ctxt=0x816c7f8) at types.c:328
#4  0x400924c6 in pythonExternalEntityLoader (
    URL=0x8184cb8 "simplestruct2.ent", ID=0x0, ctxt=0x816c7f8) at libxml.c:435
#5  0x400f10ae in xmlLoadExternalEntity (URL=0x8184cb8 "simplestruct2.ent",
    ID=0x0, ctxt=0x816c7f8) at xmlIO.c:2731
#6  0x400e4c0d in xmlCreateEntityParserCtxt (
    URL=0x81dec18 "simplestruct2.ent", ID=0x0, base=0x0) at parser.c:10270
#7  0x400e3cb9 in xmlParseCtxtExternalEntity (ctx=0x81f01d0,
    URL=0x8184c60 "¥Z", ID=0x4212b190 "", lst=0xbfffee88) at parser.c:9480
#8  0x400ca41d in getEntity (ctx=0x81f01d0, name=0x81cbdb0 "simplestruct2.ent")
    at SAX.c:387

  Could you fix this ?

   thanks,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



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