[redland-dev] raptor: possible memory leak when an element is not closed properly

[Dave Beckett]

On Fri, 21 May 2004 15:11:07 -0400, Mark Smith <mcs at umich.edu> wrote:
> I am experimenting with Raptor on Linux (RH 9.0+).  Valgrind reports a 
> memory leak for RDFXML documents that contain elements that are no 
> closed properly.  Here is an example:
> 
> <r:RDF
>         xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>         xmlns:dc="http://purl.org/dc/elements/1.0/">
>         <r:Description>
>                 <dc:subject>bookmark</dc:subject>
>                 <dc:language>en</dc:languagXXXXXXe>
>         </r:Description>
> </r:RDF>
> 
> Save the above as /tmp/invalid.xml and execute this command to see the leak:
> 
> valgrind --num-callers=25 --leak-check=yes ./rapper -i rdfxml 
> /tmp/invalid.xml
> 
> Here is the relevant portion of the valgrind output:
> 
> ==4162== 40 bytes in 1 blocks are definitely lost in loss record 3 of 6
> ==4162==    at 0x40029B2A: calloc (vg_replace_malloc.c:284)
> ==4162==    by 0x40234DE2: raptor_new_sax2_element (raptor_sax2.c:86)
> ==4162==    by 0x402279B4: raptor_xml_start_element_handler 
> (raptor_parse.c:798)
> ==4162==    by 0x4024AE80: (within /usr/lib/libexpat.so.0.4.0)
> ==4162==    by 0x4024A72A: (within /usr/lib/libexpat.so.0.4.0)
> ==4162==    by 0x4024D29D: (within /usr/lib/libexpat.so.0.4.0)
> ==4162==    by 0x4024D0B0: (within /usr/lib/libexpat.so.0.4.0)
> ==4162==    by 0x4024A1BA: XML_ParseBuffer (in /usr/lib/libexpat.so.0.4.0)
> ==4162==    by 0x4024A14C: XML_Parse (in /usr/lib/libexpat.so.0.4.0)
> ==4162==    by 0x40228A3A: raptor_xml_parse_chunk_ (raptor_parse.c:1489)
> ==4162==    by 0x40228A9D: raptor_xml_parse_chunk (raptor_parse.c:1561)
> ==4162==    by 0x40230288: raptor_parse_chunk (raptor_general.c:452)
> ==4162==    by 0x40230423: raptor_parse_file_stream (raptor_general.c:517)
> ==4162==    by 0x4023055F: raptor_parse_file (raptor_general.c:566)
> ==4162==    by 0x8049C4E: main (rdfdump.c:521)
> ==4162==    by 0x4027C8C6: __libc_start_main (in /lib/libc-2.3.2.so)

Yes, I can duplicate this with raptor+expat as well as raptor+libxml.

It is due to the error causing the parser to fail to cleanup some state.

> I am not familiar enough with the raptor code to propose a fix, but it 
> seems like some change needs to be made to raptor_free_parser() to clean 
> up the sax2_elements.

I've added a fix for this to the Raptor CVS and it now doesn't leak any
memory on such failures.

Thanks for the bug report

Dave