Thread: contrib/xml2 pfree bug
Didn't we just clean up a mess in our XML handling to do with memory handlers? It looks like contrib/xml2 might have similar problems. Here's the relevant part of a back trace from a core dump: Program terminated with signal 11, Segmentation fault. #0 0x000000000069300a in pfree () (gdb) bt #0 0x000000000069300a in pfree () #1 0x000000356c42e0ee in xmlCleanupCharEncodingHandlers () from /usr/lib64/libxml2.so.2 #2 0x000000356c436675 in xmlCleanupParser () from /usr/lib64/libxml2.so.2 #3 0x00002aaab072c5b6 in xslt_process () from /bk/xxxx/dbinst-84/lib/postgresql/pgxml.so this was generated from the following call (XML afficionados will realise I was trying to pretty print the XML): select xslt_process( cb_ob_invoice_xml(1,1)::text, $$<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" indent="yes" /> <xsl:template match="*"> <xsl:copy> <xsl:copy-of select="@*" /> <xsl:apply-templates /> </xsl:copy> </xsl:template> <xsl:template match="comment()|processing-instruction()"> <xsl:copy /> </xsl:template> </xsl:stylesheet> $$::text ); cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Didn't we just clean up a mess in our XML handling to do with memory
> handlers? It looks like contrib/xml2 might have similar problems.
Yeah, it's using xmlMemSetup(), and being even less careful than the
core code was :-(.
Do we feel like fixing it, or is it time to rip it out?
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Didn't we just clean up a mess in our XML handling to do with memory >> handlers? It looks like contrib/xml2 might have similar problems. >> > > Yeah, it's using xmlMemSetup(), and being even less careful than the > core code was :-(. > > Do we feel like fixing it, or is it time to rip it out? > > > Well, we don't have an XSLT processor in core code. If we get one, we should rip this module out from HEAD. But this is a bug in released code - we don't want to rip that out, right? It works OK in some circumstances, but crashing it was trivially easy. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Didn't we just clean up a mess in our XML handling to do with memory
> handlers? It looks like contrib/xml2 might have similar problems.
BTW, I couldn't duplicate this because I don't know what
cb_ob_invoice_xml(1,1) refers to. Can you provide a self-contained
example?
regards, tom lane
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Didn't we just clean up a mess in our XML handling to do with memory
>> handlers? It looks like contrib/xml2 might have similar problems.
>>
>
> BTW, I couldn't duplicate this because I don't know what
> cb_ob_invoice_xml(1,1) refers to. Can you provide a self-contained
> example?
>
Almost any XML will do for the first param. e.g.:
select xslt_process( query_to_xml('select x from generate_series(1,5) as
x',true,false,'')::text,
$$<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" />
<xsl:template match="*"> <xsl:copy> <xsl:copy-of select="@*" /> <xsl:apply-templates /> </xsl:copy>
</xsl:template>
<xsl:template match="comment()|processing-instruction()"> <xsl:copy />
</xsl:template>
</xsl:stylesheet>
$$::text);
cheers
andrew
Andrew Dunstan wrote:
>
>
>
> Almost any XML will do for the first param. e.g.:
It looks like you need to make sure the XML library is called first to
induce the crash, so before doing what's below, do:
select query_to_xml('select 1 as x',true,false,''):
>
> select xslt_process( query_to_xml('select x from generate_series(1,5)
> as x',true,false,'')::text,
> $$<xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:output method="xml" indent="yes" />
> <xsl:template match="*">
> <xsl:copy>
> <xsl:copy-of select="@*" />
> <xsl:apply-templates />
> </xsl:copy>
> </xsl:template>
> <xsl:template match="comment()|processing-instruction()">
> <xsl:copy />
> </xsl:template>
> </xsl:stylesheet>
> $$::text);
>
cheers
andrew