I wrote:
> I was able to reproduce this after replacing those VARCHAR2's with
> VARCHAR. I added some debugging elog's (attached), and it looks like
> libxml2 is trying xml_pfree a pointer we never gave it in any of the
> alloc functions. Log attached, last xml_pfree crashes and it's the first
> time 853c180 is mentioned.
Looking closer, I think it's a memory management bug on our end. I
hadn't looked at the way we use palloc with xml before.
So my current theory is:
In xmlelement(), we use ExecEvalExpr(), which in turn calls xml_parse.
xml_parse calls xmlCleanupParser(). But when we call ExecEvalExpr(),
we're in the middle of constructing an xml buffer, so calling
xmlCleanupBuffer() probably frees something we still need.
Does that sound plausible to you libxml experts out there? If so, how
about we move the calls to ExecEvalExpr() before we start building the
xml buffer?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
