[Expat-bugs] [ expat-Bugs-676926 ] memory leak in xmlparse.c::doProlog()

[SourceForge.net]

Bugs item #676926, was opened at 2003-01-29 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127

Category: None
>Group: Not a Bug
Status: Open
>Resolution: Rejected
>Priority: 9
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: memory leak in xmlparse.c::doProlog()

Initial Comment:
As of now, 2003/1/29, there is a memory leak in
xmlparse.c::doProlog() line 3979.

The XML_Content is dynamically allocated, but never
freed in the block.  The lifetime of the variable
content is not clear.  It is passed to
elementDeclHandler().  Does content need to be dynamic,
or can it be a local (stack) variable?  Does
elementDeclHandler() take ownership of content?

I can make the change in Python (which is where this
problem was found from test_minidom).

20 bytes in 1 blocks are definitely lost in loss record
2 of 15
  at 0x4015D480: malloc (vg_clientfuncs.c:100)
doProlog (python/dist/src/Modules/expat/xmlparse.c:3979)
prologProcessor
(python/dist/src/Modules/expat/xmlparse.c:3185)
prologInitProcessor
(python/dist/src/Modules/expat/xmlparse.c:3016)
XML_ParseBuffer
(python/dist/src/Modules/expat/xmlparse.c:1439)
XML_Parse (python/dist/src/Modules/expat/xmlparse.c:1427)
xmlparse_Parse (python/dist/src/Modules/pyexpat.c:853)


----------------------------------------------------------------------

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 14:03

Message:
Logged In: YES 
user_id=290026

The content model needs to be freed by the application,
which is documented in reference.html.

We added a new API call in the current release,
XML_FreeContentModel, to make it easier for
non-C languages to free the content model
passed to the elemenDeclHandler.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:59

Message:
Logged In: YES 
user_id=3066

Oops, didn't mean to set the priority *that* high; it's a leak, 
not a segfault!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127