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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sokolov Yura <funny(dot)falcon(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: BUG #3860: xpath crashes backend when is querying xmlagg result
Date: 2008-01-09 22:42:19
Message-ID: 20080109224219.GA22548@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-patches

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 already,
> and it doesn't seem to be preventing the problem.

We call it *after* the context has been reset -- or at least that's what
gdb is showing me.

Hardware watchpoint 3: handlers[0]

Old value = (xmlCharEncodingHandlerPtr) 0xc43580
New value = (xmlCharEncodingHandlerPtr) 0x7f7f7f7f7f7f7f7f
0x00002b579ad84283 in memset () from /lib/libc.so.6
(gdb) bt
#0 0x00002b579ad84283 in memset () from /lib/libc.so.6
#1 0x0000000000768b69 in AllocSetReset (context=0xc1d970)
at /pgsql/source/00head/src/backend/utils/mmgr/aset.c:456
#2 0x0000000000769f42 in MemoryContextReset (context=0xc1d970)
at /pgsql/source/00head/src/backend/utils/mmgr/mcxt.c:130
#3 0x000000000059791c in ReScanExprContext (econtext=0xc42050)
at /pgsql/source/00head/src/backend/executor/execUtils.c:447
#4 0x00000000005a6ed8 in ValuesNext (node=0xc41f38)
at /pgsql/source/00head/src/backend/executor/nodeValuesscan.c:106
#5 0x00000000005957ec in ExecScan (node=0xc41f38,
accessMtd=0x5a6d98 <ValuesNext>)
at /pgsql/source/00head/src/backend/executor/execScan.c:68
#6 0x00000000005a706c in ExecValuesScan (node=0xc41f38)
at /pgsql/source/00head/src/backend/executor/nodeValuesscan.c:173
#7 0x000000000058b6bd in ExecProcNode (node=0xc41f38)
at /pgsql/source/00head/src/backend/executor/execProcnode.c:360
#8 0x000000000059b86b in agg_retrieve_direct (aggstate=0xc41448)
at /pgsql/source/00head/src/backend/executor/nodeAgg.c:921
#9 0x000000000059b6d0 in ExecAgg (node=0xc41448)
at /pgsql/source/00head/src/backend/executor/nodeAgg.c:816
#10 0x000000000058b73b in ExecProcNode (node=0xc41448)
at /pgsql/source/00head/src/backend/executor/execProcnode.c:394
#11 0x0000000000588e50 in ExecutePlan (estate=0xc40f18, planstate=0xc41448,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
dest=0xc31748) at /pgsql/source/00head/src/backend/executor/execMain.c:1233
#12 0x000000000058760a in ExecutorRun (queryDesc=0xc09f78,
direction=ForwardScanDirection, count=0)
at /pgsql/source/00head/src/backend/executor/execMain.c:267
#13 0x000000000066715b in PortalRunSelect (portal=0xc382f8, forward=1 '\001',
count=0, dest=0xc31748) at /pgsql/source/00head/src/backend/tcop/pquery.c:943
#14 0x0000000000666dab in PortalRun (portal=0xc382f8, count=9223372036854775807,
isTopLevel=1 '\001', dest=0xc31748, altdest=0xc31748,
completionTag=0x7fff10f94cf0 "")
at /pgsql/source/00head/src/backend/tcop/pquery.c:769
#15 0x000000000066125f in exec_simple_query (
query_string=0xbf4938 "select xpath('any_non_empty_expression', xmlagg(el) ) as el\nfrom ( values\n ( xmlelement(name b, 0) ),\n ( xmlelement(name c, 0.1) )\n) as t(el);") at /pgsql/source/00head/src/backend/tcop/postgres.c:963
[...]

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2008-01-09 23:01:42 Re: BUG #3860: xpath crashes backend when is querying xmlagg result
Previous Message Andrew Gilligan 2008-01-09 22:37:57 BUG #3866: Segfault during table update when using convert_from()

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2008-01-09 23:01:42 Re: BUG #3860: xpath crashes backend when is querying xmlagg result
Previous Message Tom Lane 2008-01-09 19:54:55 Re: OUTER JOIN performance regression remains in 8.3beta4