Re: [PATCH] Code refactoring related to -fsanitize=use-after-scope - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Code refactoring related to -fsanitize=use-after-scope
Date
Msg-id 14147.1455564002@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Code refactoring related to -fsanitize=use-after-scope  (Andres Freund <andres@anarazel.de>)
Responses Re: [PATCH] Code refactoring related to -fsanitize=use-after-scope
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2016-02-15 14:37:28 +0100, Martin Liška wrote:
>> I've been currently working on support of -sanitize=use-after-scope in the GCC compiler and
>> I decided to use postgresql as my test-case. The sanitation poisons every stack variable at the
>> very beginning of a function, unpoisons a variable at the beginning of scope definition and finally
>> poisons the variable again at the end of scope.

> Generally sounds like a good check.

>> Following patch fixes issues seen by the sanitizer. Hope it's acceptable?
>> With the patch applied, ASAN (with the new sanitization) works fine.

> But I'm not immediately seing why this is necessary? Is this about
> battling a false positive?

I bet a nickel that this is triggered by the goto leading into those
variables' scope ("goto process_inner_tuple" at line 2038 in HEAD).
That probably bypasses the "unpoison" step.

However, doesn't this represent a bug in the sanitizer rather than
anything we should change in Postgres?  There is no rule in C that
you can't execute such a goto, especially not if there is no
initialization of those variables.

If you can think of a reasonable refactoring that gets rid of the need
for that goto, I'd be for that, because it's certainly unsightly.
But I don't think it's wrong, and I don't think that the proposed patch
is any improvement from a structured-programming standpoint.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: xlc atomics
Next
From: Peter Geoghegan
Date:
Subject: Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?