Обсуждение: 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@ymail.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@sss.pgh.pa.us> wrote:> Kevin Grittner <kgrittn@ymail.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