[cfe-dev] Clang Static Analyzer Round Table

Gábor Márton via cfe-dev cfe-dev at lists.llvm.org
Thu Oct 28 08:54:37 PDT 2021


+ Randell

Hi Randell,

Thank you for your email, I am forwarding it to the list.

>  Is the list set up to block new subscribers from posting until
moderators review?
I really don't know, maybe someone in the list will know.


On Thu, Oct 28, 2021 at 3:41 PM Randell Jesup <rjesup at mozilla.com> wrote:

> On 10/26/2021 4:09 AM, Gábor Márton via cfe-dev wrote:
>
> Hi CSA developers,
>
> I've submitted a round table request for the upcoming Dev Meeting (Nov
> 17-19). Would be great to have a discussion.
> Please also invite colleagues who you think might be interested.
>
>
> Hi Gabor.  I recently joined the cfe-dev mailing list, but have been
> unable to post to it.  Is the list set up to block new subscribers from
> posting until moderators review?   Thanks
>
>
> This is what I was trying to send:
>
> Subject: Thread-safety analysis rough edges
>
> I've been working with -Wthread-safety, and have run into a few rough
> edges.
>
> One is RAII unlockers.   As stated in the known limitations, it doesn't
> handle an RAII unlocker and gets very confused, leading to follow-on false
> positives.   Is the only reasonable solution to simply not annotating the
> RAII unlocker class, and live with the analysis being wrong during the
> unlocked section?
>
> Is there any ongoing work to resolve this issue?
>
> I notice the work done by WebKit to use this functionality to do static
> thread assertions (
> https://webkit-search.igalia.com/webkit/source/Source/WTF/wtf/ThreadAssertions.h).
> There seems to be some value here (witness the shift from lock-centric
> names), but examples on how to use it would be good, similar to the mutex.h
> in the docs.
>
> Related: There are a number of usage patterns for Mutexes that don't lend
> themselves easily to thread-safety annotations.  An example would be a item
> written to from only a single thread, but read from other threads.   The
> lock must be held to write it, and all off-writer-thread accesses must lock
> to access it.  However, on-writer-thread accesses *don't* need to lock, and
> will generate false positives.  (There are other Mutex patterns, like free
> access until the item is made available to other threads, or after all
> other threads are known to have exited, and more, which aren't easily
> covered.)
>
> What's the best way to handle this, other than not adding GUARDED_BY() or
> using NO_THREAD_SAFETY_ANALYSIS?  Could we mark an item as requiring one of
> a set of capabilities?  (i.e. on the correct thread OR holds the mutex?)
>
> Thanks,
> Randell Jesup, Mozilla
>

On Thu, Oct 28, 2021 at 12:23 AM Artem Dergachev <noqnoqneo at gmail.com>
wrote:

> +Andrew and Bruno who attended our tiny cozy static analyzer round table
> at the bay area meetup!
>
> Andrew, you have some notes from that round table, do you think it makes
> sense to share them in this mailing list thread?
>
> On 10/26/21 12:26 PM, Artem Dergachev wrote:
> > +Deep because he expressed interest.
> >
> > Yay! Yes, absolutely, let's have that.
> >
> > On 10/26/21 1:09 AM, Gábor Márton wrote:
> >> Hi CSA developers,
> >>
> >> I've submitted a round table request for the upcoming Dev Meeting
> >> (Nov 17-19). Would be great to have a discussion.
> >> Please also invite colleagues who you think might be interested.
> >>
> >> Thanks,
> >> Gabor
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211028/fc65d75c/attachment.html>


More information about the cfe-dev mailing list