Re: BUG #3860: xpath crashes backend when is querying xmlagg result

Tom Lane escribió:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Hmm, what I'm seeing is that libxml is apparently trying to pfree
> > something that it didn't allocate via palloc ...
>
> Not totally surprising --- when we call xmlMemSetup() we are telling
> libxml to start using xml_palloc etc rather than its default of malloc
> etc. We had some bugs earlier involving not calling xmlMemSetup soon
> enough during some seqauence of operations; this may be another.

The crash is on free of the character encoding stuff in libxml. So I
traced its initialization and xmlMemSetup, and my conclusion that this
is not the problem -- xmlMemSetup is called earlier.

> Another likely theory is that libxml is trying to pfree something that
> had been palloc'd in a previous cycle of function calls, and then went
> away in a memory context reset. We try to shut the library down
> completely at exit from xml.c functions, so that it doesn't think it has
> any open allocated memory, buut there may be something we've missed
> doing. See the note at lines 27ff of xml.c.

[ ... a lot of playing with gdb later, including clearing up confusion
between tracepoints and watchpoints ... ]

What's happening is that libxml encoding handler table is being
allocated in an ExprContext which apparently is too short-lived.

I'm not seeing very well how to handle this -- one idea would be to
manually call xmlInitCharEncodingHandlers (which is public but supposed
to be called internally by libxml) with a longer-lived context, but I
wonder whether there's some other initialization that will come bite us.
Another idea would be to initialize and then destroy the libxml state
separately for each expression, which perhaps doesn't really work at
all.

Perhaps a better idea is to create a separate LibxmlContext memcxt,
child of QueryContext, and have xml_palloc etc always use that. That
way it won't be reset between calls. It probably also means we could
wire xml reset to transaction abort, making it a bit simpler.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support