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
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 |