Re: [PATCH] Detect escape of ErrorContextCallback stack pointers (and from PG_TRY() )

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: [PATCH] Detect escape of ErrorContextCallback stack pointers (and from PG_TRY() )
Date: 2020-09-04 06:55:01
Message-ID: CAMsr+YENpG2nU3aTxWX_T=+g-dsyZoR6bPqUxEro7YKuwYr9Tw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 4 Sep 2020 at 14:13, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

>
> I actually had a pretty good look around for static analysis options to
> see if I could find anything that might help us out before I landed up with
> this approach.
>

Apparently not good enough.

https://clang.llvm.org/docs/analyzer/checkers.html#core-stackaddressescape-c

Using a test program:

return_stack_escape.c:14:3: warning: Address of stack memory associated
with local variable 'g' is still referred to by the global variable
'guard_ptr' upon returning to the caller. This will be a dangling reference
return do_fail;
^~~~~~~~~~~~~~
1 warning generated.

so ... that's interesting. I'll need to do some checking and verify that
it's effective on the actual problem I originally had, but if so, I shall
proceed with kicking myself now.

Handily, the same thing can be used to detect PG_TRY() escapes.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2020-09-04 07:01:41 Division in dynahash.c due to HASH_FFACTOR
Previous Message Peter Eisentraut 2020-09-04 06:52:56 Re: Change JOIN tutorial to focus more on explicit joins