[LLVMbugs] [Bug 17839] New: [MallocChecker] An Obj-C Method named initWithBytesNoCopy does not always transfer ownership

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Nov 7 10:04:58 PST 2013


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

            Bug ID: 17839
           Summary: [MallocChecker] An Obj-C Method named
                    initWithBytesNoCopy does not always transfer ownership
           Product: clang
           Version: 3.3
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: hanauska at equinux.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The MallocChecker incorrectly assumes, that an Objective-C method whose name
starts with "initWithBytesNoCopy" always means that ownership of memory is
transferred, unless there is also a "freeWhenDone" in the method name. Just
because this is how NSData works doesn't mean it the same way how all other
objects on earth with a method of that name work.

In my case I wrote an object, whose method is named:

"initWithBytesNoCopy:length:releaseCallback:"

and release callback is an optional block. If set, the block is called with the
byte pointer as argument and may or may not release the memory; if not set (if
NULL) it will not even be called and thus nothing is ever freed for sure.

The analyzer says that this is an error, because memory because "non-owned"
memory well be freed by this method, even though I set no releaseCallback.

The analyzer should really not pretend to understand the meaning of methods,
unless this meaning is really known (e.g. for NSData it is known and will
certainly not change for compatibility reasons).

Here's an excerpt from MallocChecker, showing the code culprit:

00685 static bool isKnownDeallocObjCMethodName(const ObjCMethodCall &Call) {
00686   // If the first selector piece is one of the names below, assume that
the
00687   // object takes ownership of the memory, promising to eventually
deallocate it
00688   // with free().
00689   // Ex:  [NSData dataWithBytesNoCopy:bytes length:10];
00690   // (...unless a 'freeWhenDone' parameter is false, but that's checked
later.)
00691   StringRef FirstSlot = Call.getSelector().getNameForSlot(0);
00692   if (FirstSlot == "dataWithBytesNoCopy" ||
00693       FirstSlot == "initWithBytesNoCopy" ||
00694       FirstSlot == "initWithCharactersNoCopy")
00695     return true;
00696 
00697   return false;
00698 }
00699 
00700 static Optional<bool> getFreeWhenDoneArg(const ObjCMethodCall &Call) {
00701   Selector S = Call.getSelector();
00702 
00703   // FIXME: We should not rely on fully-constrained symbols being folded.
00704   for (unsigned i = 1; i < S.getNumArgs(); ++i)
00705     if (S.getNameForSlot(i).equals("freeWhenDone"))
00706       return !Call.getArgSVal(i).isZeroConstant();
00707 
00708   return None;
00709 }

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131107/b0fb69f2/attachment.html>


More information about the llvm-bugs mailing list