Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy() - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy()
Date
Msg-id CAM3SWZRNbuJ5OJBDH08+B9ZdwQpbV2p-GcnZ+18BUq0p7tVp+A@mail.gmail.com
Whole thread Raw
Responses Re: Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy()
Re: Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy()
List pgsql-hackers
I see the following Valgrind warnings in a recent build of the master branch:

--1159-- REDIR: 0x5f73450 (strstr) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--1159-- REDIR: 0x5f88cb0 (__strstr_sse2_unaligned) redirected to
0x4c31fa0 (strstr)
2014-09-29 14:49:24.342 PDT 1159 LOG:  statement: CREATE POLICY p1 ON document  USING (dlevel <= (SELECT seclv FROM
uaccountWHERE pguser = current_user));
 
==1159== Invalid read of size 8
==1159==    at 0x4C2F790: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1159==    by 0x461601: heap_fill_tuple (heaptuple.c:248)
==1159==    by 0x46284E: heap_form_tuple (heaptuple.c:737)
==1159==    by 0x5FD143: CreatePolicy (policy.c:583)
==1159==    by 0x7BA16B: ProcessUtilitySlow (utility.c:1325)
==1159==    by 0x7B9438: standard_ProcessUtility (utility.c:838)
==1159==    by 0x7B86D7: ProcessUtility (utility.c:312)
==1159==    by 0x7B77B8: PortalRunUtility (pquery.c:1187)
==1159==    by 0x7B7987: PortalRunMulti (pquery.c:1318)
==1159==    by 0x7B6ECB: PortalRun (pquery.c:816)
==1159==    by 0x7B0BE4: exec_simple_query (postgres.c:1045)
==1159==    by 0x7B4FCE: PostgresMain (postgres.c:4010)
==1159==  Address 0x6acfd20 is 0 bytes inside a block of size 3 client-defined
==1159==    at 0x91CEE7: palloc (mcxt.c:702)
==1159==    by 0x5B8720: downcase_truncate_identifier (scansup.c:137)
==1159==    by 0x58B0A1: core_yylex (scan.l:963)
==1159==    by 0x58E19D: base_yylex (parser.c:99)
==1159==    by 0x562A8E: base_yyparse (gram.c:20285)
==1159==    by 0x58E109: raw_parser (parser.c:52)
==1159==    by 0x7B0408: pg_parse_query (postgres.c:563)
==1159==    by 0x7B0839: exec_simple_query (postgres.c:879)
==1159==    by 0x7B4FCE: PostgresMain (postgres.c:4010)
==1159==    by 0x739932: BackendRun (postmaster.c:4112)
==1159==    by 0x739011: BackendStartup (postmaster.c:3787)
==1159==    by 0x73580A: ServerLoop (postmaster.c:1566)
==1159==
{  <insert_a_suppression_name_here>  Memcheck:Addr8  fun:memcpy@@GLIBC_2.14  fun:heap_fill_tuple  fun:heap_form_tuple
fun:CreatePolicy fun:ProcessUtilitySlow  fun:standard_ProcessUtility  fun:ProcessUtility  fun:PortalRunUtility
fun:PortalRunMulti fun:PortalRun  fun:exec_simple_query  fun:PostgresMain
 
}

This appears a few times, but always seems to occur with the same call stack.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}