address sanitizer crash

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: address sanitizer crash
Date: 2013-11-22 13:40:27
Message-ID: 528F5ECB.4090701@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Golub 2013-11-22 14:07:07 Re: commit fest 2013-11 week 1 report
Previous Message Andres Freund 2013-11-22 13:38:08 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1