Re: Getting server crash after running sqlsmith

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting server crash after running sqlsmith
Date: 2017-05-23 23:45:43
Message-ID: CA+TgmoZizquq+b=TJMzGdRoQoPJqvbtYqU2C3HY=YWOGFJEyDw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 23, 2017 at 9:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Just out of curiosity, what happens if you try it with the attached patch?
>
> Surely that's pretty unsafe?

Yes. I was just curious to see whether it would work. I think what
we need to do is teach pqsignal() to block all of the necessary
signals using sa_mask and then remove all of the explicit
blocking/unblocking logic from the signal handlers themselves. IIUC,
the point of sa_mask is precisely that you want the operating system
to handle the save/restore of the signal mask rather than doing it
yourself in the handler, precisely because doing it in the handler
creates windows at the beginning and end of the handler where the mask
may not be what you want.

In the case of Linux and MacOS, at least, the default behavior (unless
SA_NODEFER is set) is to automatically block the signal currently
being handled, so there's likely no way to blow out the stack during
the brief window before PG_SETMASK(&BlockSig) is called. You could
receive some *other* signal during that window, but then that one
would blocked too, so I don't think you can stack up more frames this
way than the number of distinct signal handlers you have. However,
the window at the end of the function - after PG_SETMASK(&UnBlockSig)
has been invoked - can recurse arbitrarily deep. At that point we've
unblocked the signal we're currently handling, so we're playing with
fire.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-05-24 02:47:07 Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression
Previous Message Euler Taveira 2017-05-23 23:36:21 Re: PG 10 release notes