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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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