Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy()

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy()
Date: 2014-09-29 22:04:02
Message-ID: CAM3SWZRNbuJ5OJBDH08+B9ZdwQpbV2p-GcnZ+18BUq0p7tVp+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 uaccount WHERE 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-09-29 22:05:46 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Andres Freund 2014-09-29 22:02:23 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}