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