[LLVMbugs] [Bug 11578] New: clang-sa doesn't track retains across block boundaries

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Dec 14 16:36:30 PST 2011


http://llvm.org/bugs/show_bug.cgi?id=11578

             Bug #: 11578
           Summary: clang-sa doesn't track retains across block boundaries
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7738
  --> http://llvm.org/bugs/attachment.cgi?id=7738
test case

The attached sample is narrowed down from a real method we have. We have a
__block variable (which is non-retaining when captured by blocks, so we have to
retain when assigning into it under MRR). This variable gets filled out in one
synchronously executing block (NSFileCoordinator), double-checked on the
mainline code, and then used and autoreleased in a delayed block.

I'm not sure if it is possible for clang-sa to properly track this w/o knowing
that NSOperationQueue takes blocks that will get executed exactly once
(assuming no deadlock, cancellation, etc).

This code used to not warn in previously versions, but does now in "clang
version 3.1 (trunk 146587)". This may actually be a fix and the correct
behavior, but it is a bit annoying since it seems like it should be possible.

One alternate approach would be to declare another local:

  NSDate *date = [modificationDate autorelease];

that the second block could capture (and *would* retain and release as needed
by the lifetime of the second block). This extra variable is kind of strange
(and hard to name) but maybe this is the right way to color w/in the lines
here.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list