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-08 02:27:11
Message-ID: CAMsr+YGMZG6SrF6NpTaCCjktPQzmauCVrD_6CoOOvLwMRWacsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> 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.
>
>
Example here:

https://github.com/ringerc/scrapcode/tree/master/c/clang_return_stack_checks

So I find that actually, the __attribute__((callback(fn)) approach is
unnecessary for the purpose proposed.

I still think we should be looking at tidying up the error contexts API,
but it's easy enough for extensions to provide a wrapper over it, so that's
not a big deal really.

I will submit my docs patches separately to ensure they get some attention,
and I'll experiment with llvm threadsafety annotations / capabilities.

--
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 Fujii Masao 2020-09-08 02:35:22 Re: Transactions involving multiple postgres foreign servers, take 2
Previous Message Masahiko Sawada 2020-09-08 02:23:10 Re: Resetting spilled txn statistics in pg_stat_replication