parser_analyze freeing memory which is later referenced
От | Kevin Grittner |
---|---|
Тема | parser_analyze freeing memory which is later referenced |
Дата | |
Msg-id | 1360613721.51134.YahooMailNeo@web162905.mail.bf1.yahoo.com обсуждение исходный текст |
Ответы |
Re: parser_analyze freeing memory which is later referenced
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: