AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
(also available through gcc, but I used clang), reports one bug, which
I traced down to this code in ruleutils.c:
[elsewhere:]
#define ViewSelectRuleName "_RETURN"
/*
* Get the pg_rewrite tuple for the view's SELECT rule
*/
args[0] = ObjectIdGetDatum(viewoid);
args[1] = PointerGetDatum(ViewSelectRuleName);
nulls[0] = ' ';
nulls[1] = ' ';
spirc = SPI_execute_plan(plan_getviewrule, args, nulls, true, 2);
[I also think that the 2 here is wrong, probably thinking it means 2
arguments, but it means 2 result rows, but only one is needed. But
that's unrelated to the bug.]
The datums end up in datumCopy(), which tries to copy 64 bytes of
"name" data, overrunning the end of the string.
I think the correct code is something like
args[1] = DirectFunctionCall1(namein, CStringGetDatum(ViewSelectRuleName));
which indeed makes the crash go away. (A more explicit string-to-name
function might be useful and could also be used in other places.)
This is the only remaining issue found by AddressSanitizer that is
clearly attributable to the PostgreSQL source code (after the recently
fixed issue with memcpy with identical arguments). There are crashes
in PL/Perl and PL/Python, but it's not clear to me yet whose fault
they are.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
