From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: longjmp clobber warnings are utterly broken in modern gcc |
Date: | 2015-01-26 16:04:05 |
Message-ID: | 20150126160405.GD9916@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-01-26 10:52:07 -0500, Robert Haas wrote:
> On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > This is scary as hell. I intend to go around and manually audit
> > every single PG_TRY in the current source code, but that is obviously
> > not a long-term solution. Anybody have an idea about how we might
> > get trustworthy mechanical detection of this type of situation?
>
> One idea I've been thinking about for a while is to create some new,
> safer notation. Suppose we did this:
>
> PG_TRY_WITH_CLEANUP(cleanup_function, cleanup_argument);
> {
> /* code requiring cleanup */
> }
> PG_END_TRY_WITH_CLEANUP();
That's pretty similar to to PG_ENSURE_ERROR_CLEANUP, except that that is
also called after FATAL errors. If we do this, we probably should try to
come up with a easier to understand naming scheme. PG_TRY_WITH_CLEANUP
vs. PG_ENSURE_ERROR_CLEANUP isn't very clear to a reader.
> Instead of doing anything with sigsetjmp(), this would just push a
> frame onto a cleanup stack. We would call of those callbacks from
> innermost to outermost before doing siglongjmp(). With this design,
> we don't need any volatile-ization.
On the other hand most of the callsites will need some extra state
somewhere to keep track of what to undo. That's a bit of restructuring
work too. And if the cleanup function needs to reference anything done
in the TRY block, that state will need to be volatile too.
> Aside from any reduction in the need
> for volatile, this might actually perform slightly better, because
> sigsetjmp() is a system call on some platforms. There are probably
> few cases where that actually matters, but the one in pq_getmessage(),
> for example, might not be entirely discountable.
Hm. How would you implement PG_TRY_WITH_CLEANUP without a sigsetjmp()?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-01-26 16:18:41 | Re: longjmp clobber warnings are utterly broken in modern gcc |
Previous Message | Robert Haas | 2015-01-26 15:52:07 | Re: longjmp clobber warnings are utterly broken in modern gcc |