Horton

Re: elog(DEBUG2 in SpinLocked section.

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, masao.fujii@oss.nttdata.com, amit.kapila16@gmail.com, pasim@vmware.com, pgsql-hackers@lists.postgresql.org
Date: 2020-06-16T23:31:05Z
Lists: pgsql-hackers 
Hi,

On 2020-06-03 00:36:34 -0400, Tom Lane wrote:
> Should we think about adding automated detection of this type of
> mistake?  I don't like the attached as-is because of the #include
> footprint expansion, but maybe we can find a better way.

I experimented with making the compiler warn about about some of these
kinds of mistakes without needing full test coverage:

I was able to get clang to warn about things like using palloc in signal
handlers, or using palloc while holding a spinlock. Which would be
great, except that it doesn't warn when there's an un-annotated
intermediary function. Even when that function is in the same TU.

Here's my attempt: https://godbolt.org/z/xfa6Es

It does detect things like
    spinlock_lock();
    example_alloc(17);
    spinlock_unlock();

<source>:49:2: warning: cannot call function 'example_alloc' while mutex 'holding_spinlock' is held [-Wthread-safety-analysis]

        example_alloc(17);

        ^

which isn't too bad.

Does anybody think this would be useful even if it doesn't detect the
more complicated cases?

Greetings,

Andres Freund

Commits

  1. Fix instance of elog() called while holding a spinlock

  2. Don't call palloc() while holding a spinlock, either.

  3. Don't call elog() while holding spinlock.