Tom Lane wrote:
"Sokolov Yura" <[EMAIL PROTECTED]> writes:
xpath() crashes backend when is querying particular xmlagg results.
Please see whether this patch fixes it:
http://archives.postgresql.org/pgsql-committers/2008-01/msg00190.php
The specific examples you give seem to be fixed,
"Sokolov Yura" <[EMAIL PROTECTED]> writes:
> xpath() crashes backend when is querying particular xmlagg results.
Please see whether this patch fixes it:
http://archives.postgresql.org/pgsql-committers/2008-01/msg00190.php
The specific examples you give seem to be fixed, but that's not very
much
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> One thing I was wondering about earlier today is whether libxml isn't
>> expecting NULL-return-on-failure from the malloc-substitute routine.
>> If we take control away from it unexpectedly, I wouldn't be a bit
>> surprised if its d
Tom Lane escribió:
> One thing I was wondering about earlier today is whether libxml isn't
> expecting NULL-return-on-failure from the malloc-substitute routine.
> If we take control away from it unexpectedly, I wouldn't be a bit
> surprised if its data structures are left corrupt. This might lea
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> + void
> + AtEOXact_xml(void)
> + {
> + if (LibxmlContext == NULL)
> + return;
> +
> + MemoryContextDelete(LibxmlContext);
> + LibxmlContext = NULL;
> +
> + xmlCleanupParser();
> + }
[ blink... ] Shouldn't that be the othe
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > 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 r
Alvaro Herrera escribió:
> Tom Lane escribió:
>
> > We might be able to compromise by only resetting the context after
> > an error, but this is still only possible if we have a way to make
> > libxml let go of *all* pointers to alloc'd objects. I don't understand
> > your comment that xmlCleanup
Tom Lane escribió:
> I wonder whether the real issue here isn't that we have some functions
> that invoke libxml without ultimately doing xmlCleanupParser() ---
> xml_in being the first obvious candidate. Maybe that is the mechanism
> through which libxml ends up with dangling pointers.
Hmm. I s
I wonder whether the real issue here isn't that we have some functions
that invoke libxml without ultimately doing xmlCleanupParser() ---
xml_in being the first obvious candidate. Maybe that is the mechanism
through which libxml ends up with dangling pointers.
regards, tom
Tom Lane escribió:
> We might be able to compromise by only resetting the context after
> an error, but this is still only possible if we have a way to make
> libxml let go of *all* pointers to alloc'd objects. I don't understand
> your comment that xmlCleanupParser solves it --- we call that alr
Alvaro Herrera escribió:
> Tom Lane escribió:
>
> > We might be able to compromise by only resetting the context after
> > an error, but this is still only possible if we have a way to make
> > libxml let go of *all* pointers to alloc'd objects. I don't understand
> > your comment that xmlCleanup
Tom Lane escribió:
> We might be able to compromise by only resetting the context after
> an error, but this is still only possible if we have a way to make
> libxml let go of *all* pointers to alloc'd objects. I don't understand
> your comment that xmlCleanupParser solves it --- we call that alr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What problem you have with it having its own memory context? I don't
> think it has any particular disadvantage.
I don't object to that per se; I'm just saying it doesn't do much to
fix the problem. The difficulty we've got here ultimately comes down
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > 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 xmlIn
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> 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 i
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> 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
Alvaro Herrera <[EMAIL PROTECTED]> 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 mal
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I can reproduce this crash. The backtrace looks like this:
Hmm, what I'm seeing is that libxml is apparently trying to pfree
something that it didn't allocate via palloc ...
--
Alvaro Herrerahtt
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I can reproduce this crash. The backtrace looks like this:
Ah, good. This looks like it matches a previous report, but we didn't have
a reproducible test case:
http://archives.postgresql.org/pgsql-general/2007-12/msg01086.php
Sokolov Yura escribió:
> bg1.sql---
> -- crashed, when queries xmlelement with containment given by xmlagg
> -- and type of aggregated elements is different
> select xpath('any_non_empty_expression', xmlelement(name a, xmlagg(el) )) as
> el
> from ( values
> ( xmlelement(
The following bug has been logged online:
Bug reference: 3860
Logged by: Sokolov Yura
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta4
Operating system: Debian Linux 4.0r2 both 32bit and amd64
Description:xpath crashes backend when is querying xmlagg resu
21 matches
Mail list logo
