parser_analyze freeing memory which is later referenced

I'm using valgrind to find a problem with materialized views, and
ran into this, which I have confirmed is present on the master
branch as of 7803e9327db3788f68d820c19f4081afb79edd12.

Memory freed here:

   at 0x76E3AF: pfree (mcxt.c:677)
   by 0x50861E: parse_analyze (analyze.c:105)
   by 0x684FF2: pg_analyze_and_rewrite (postgres.c:613)
   by 0x686489: PostgresMain (postgres.c:974)
   by 0x45B2C9: ServerLoop (postmaster.c:3989)
   by 0x63DC90: PostmasterMain (postmaster.c:1244)
   by 0x45BBE8: main (main.c:197)

... is later referenced at these places:

Invalid read of size 8
   at 0x5D401C7: __GI___strncasecmp_l (strcmp.S:215)
   by 0x5CF2774: ____strtod_l_internal (strtod_l.c:579)
   by 0x6B91BD: float8in (float.c:420)
   by 0x75521B: InputFunctionCall (fmgr.c:1916)
   by 0x755512: OidInputFunctionCall (fmgr.c:2047)
   by 0x52A684: coerce_type (parse_coerce.c:303)
   by 0x52AE4B: coerce_to_target_type (parse_coerce.c:101)
   by 0x52EBDD: transformExprRecurse (parse_expr.c:2222)
   by 0x52F3BA: transformExprRecurse (parse_expr.c:1249)
   by 0x530C8B: transformExpr (parse_expr.c:116)
   by 0x53B717: transformTargetEntry (parse_target.c:94)
   by 0x53B77E: transformTargetList (parse_target.c:167)

Invalid read of size 2
   by 0x45C505: heap_fill_tuple (string3.h:52)
   by 0x45D2A4: heap_form_tuple (heaptuple.c:719)
   by 0x45D8C4: heap_modify_tuple (heaptuple.c:815)
   by 0x5422C3: ExecRenameStmt (alter.c:277)
   by 0x68B5F4: standard_ProcessUtility (utility.c:780)
   by 0x687B29: PortalRunUtility (pquery.c:1185)
   by 0x688868: PortalRunMulti (pquery.c:1317)
   by 0x689519: PortalRun (pquery.c:814)
   by 0x68655A: PostgresMain (postgres.c:1048)
   by 0x45B2C9: ServerLoop (postmaster.c:3989)
   by 0x63DC90: PostmasterMain (postmaster.c:1244)

I don't want to get too sidetracked by what I went in to look for,
but I didn't want to lose track of this either.  If nobody sorts it
out before I finish what I'm looking at this issue I'm currently
on, I will come back to this.

-Kevin

Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> I'm using valgrind to find a problem with materialized views, and
> ran into this, which I have confirmed is present on the master
> branch as of 7803e9327db3788f68d820c19f4081afb79edd12.

> Memory freed here:
> ... is later referenced at these places:

[ squint... ] Not sure I believe that, as building with
CLOBBER_FREED_MEMORY (ie, any assert-enabled build) really ought to
expose such problems pretty quickly. What's your test case?

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
>> I'm using valgrind to find a problem with materialized views, and
>> ran into this, which I have confirmed is present on the master
>> branch as of 7803e9327db3788f68d820c19f4081afb79edd12.
>
>> Memory freed here:
>> ... is later referenced at these places:
>
> [ squint... ]  Not sure I believe that, as building with
> CLOBBER_FREED_MEMORY (ie, any assert-enabled build) really ought to
> expose such problems pretty quickly.  What's your test case?

make installcheck

When I get this MV issue that I'm investigating sorted out, I'll
try to narrow it to individual tests.

-Kevin