exec_execute_message crush

While inspecting a complain from a pgpool user, I found that
PostgreSQL crushes with following statck trace:

#0  0x0826436a in list_length (l=0xaabe4e28)   at ../../../src/include/nodes/pg_list.h:94
#1  0x08262168 in IsTransactionStmtList (parseTrees=0xaabe4e28)   at postgres.c:2429
#2  0x0826132e in exec_execute_message (portal_name=0x857bab0 "", max_rows=0)   at postgres.c:1824
#3  0x08263b2a in PostgresMain (argc=4, argv=0x84f6c28,   username=0x84f6b08 "t-ishii") at postgres.c:3671
#4  0x0823299e in BackendRun (port=0x8511e68) at postmaster.c:3449
#5  0x08231f78 in BackendStartup (port=0x8511e68) at postmaster.c:3063
#6  0x0822f90a in ServerLoop () at postmaster.c:1387
#7  0x0822f131 in PostmasterMain (argc=3, argv=0x84f4bf8) at postmaster.c:1040
#8  0x081c6217 in main (argc=3, argv=0x84f4bf8) at main.c:188

This happens with following extended commands sequence:

parse
bind
describe
execute
<normaly done>
parse invalid SQL thus abort a transaction
bind (error)
describe (error)
execute (crush)

exec_execute_message crushes here:
/* Does the portal contain a transaction command? */is_xact_command = IsTransactionStmtList(portal->stmts);

Looking into portal:

$5 = {name = 0x85727bc "", prepStmtName = 0x0, heap = 0x8596798, resowner = 0x0, cleanup = 0, createSubid = 1,
sourceText= 0x859ac78 " SELECT NULL AS TABLE_CAT, n.nspname AS TABLE_SCHEM,  ct.relname AS TABLE_NAME,  a.attname AS
COLUMN_NAME, a.attnum AS KEY_SEQ,  ci.relname AS PK_NAME  FROM pg_catalog.pg_namespace n, pg_catalog.pg_c"...,
commandTag= 0x84682aa "SELECT", stmts = 0xaabe4e28, cplan = 0x0, portalParams = 0x0, strategy = PORTAL_ONE_SELECT,
cursorOptions= 4, status = PORTAL_READY, queryDesc = 0x0, tupDesc = 0x85db060, formats = 0x859b0c8, holdStore = 0x0,
holdContext= 0x0, atStart = 1 '\001', atEnd = 1 '\001', posOverflow = 0 '\0', portalPos = 0, creation_time =
315313855337710,visible = 1 '\001'}
 

Problem is, stmts points to invalid memory address:

(gdb) p *portal->stmts
Cannot access memory at address 0xaabe4e28

It seems the source of the problem is, exec_execute_message tries to
execute unamed portal which has unnamed statement which has already
gone.

Please note that without pgpool backend does not crush. This is
because JDBC driver does not do execute() if prior parse, bind
etc. failed, I think.

The crush happens PostgreSQL 8.3.8, 8.3.9 and 8.4.2.

Any thought?
--
Tatsuo Ishii
SRA OSS, Inc. Japan