<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi, Brandon. It's a good idea, but unfortunately it has some problems. In C, it's totally legal to do this:</div><div><br></div><div><blockquote type="cite">int *allocate(size_t size) {</blockquote></div><div><blockquote type="cite"> int *memoryBlock = (int *)malloc(size + sizeof(int));</blockquote><blockquote type="cite"> *memoryBlock = SECRET_CODE;</blockquote><blockquote type="cite"> return &memoryBlock[1];</blockquote><blockquote type="cite">}</blockquote><br></div><div><blockquote type="cite">void deallocate(int *memoryBlock) {</blockquote><blockquote type="cite"> assert(memoryBlock[-1] == SECRET_CODE);</blockquote><blockquote type="cite"> free(&memoryBlock[-1]);</blockquote><blockquote type="cite">}</blockquote></div><div><br></div><div>I'm not sure of the best way to solve this. IIRC, by default the region '*memoryBlock' will be a SymbolicRegion backed by a RegionValueSymbol, but if 'deallocate' has been inlined the backing symbol could be a DerivedRegionSymbol or a ConjuredSymbol instead. So it'd be very hard to differentiate these cases without actually seeing the call to allocate().</div><div><br></div><div>What you could try is seeing if the base region already has malloc information. That will miss some true bugs, but it should also drastically lower the rate of false positives, since we'll only be warning about regions we <i>know</i> can be freed.</div><div><br></div><div>As far as the patch itself, your logic seems reasonable, but your style doesn't match the rest of the file or the <a href="http://llvm.org/docs/CodingStandards.html">LLVM Coding Standards</a>. In particular, please put a space after 'if', put operators at the end of the previous line instead of the start of the next line, and fit your lines in 80 columns. I'd also prefer '!offset.hasSymbolicOffset()' over 'offset.hasSymbolicOffset() == false'.</div><div><br></div><div>You'll probably want more test cases: cases where the input parameter does <i>not</i> come from malloc but has an offset, and at least one case where the input parameter comes from outside the function and has an offset.</div><div><br></div><div>Thanks for working on this!</div><div>Jordan</div><div><br></div><div><br></div><br><div><div>On Dec 15, 2012, at 21:58 , Branden Archer <<a href="mailto:b.m.archer4@gmail.com">b.m.archer4@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I have recently started looking into clang, and was interested in participating. After taking a look at the potential projects, the static checking functionality seemed interesting. Specifically, I have taken a look at the <span class="name">checker "memory.LeakPtrValChanged</span>" mentioned on the list of potential checkers page.<br>
<br>Warning: As this is my first attempt at hacking clang, I may have gone a different route than someone with more experience in the project. If something in my description or patch seems out of place, please let me know!<br>
<br>From the description, the proposed <span class="name">memory.LeakPtrValChanged checker was to only consider a pointer to newly allocated data losing its original
value. Through some investigation, I find that MemRegion objects which track pointers to memory allocations can also maintain any offset currently applied to the pointer. Using this information, the checker can reason about invalidated pointers beyond being 'newly allocated'. For example, the following case can be caught:<br>
<br>int * x = malloc(sizeof(int));<br>x += 1;<br>free(x);<br><br>However, the following is valid:<br></span><br><span class="name"><span class="name">int * x = malloc(sizeof(int));<br>x += 1;<br>free(x-1);<br><br></span>The attached patch uses the RegionOffset of freed malloc allocations to determine if the freed pointer has a non-zero offset, and post a warning in this case. If the offset is symbolic (and thus not known to be non-zero), no warning is posted. There are tests included to verify the proposed changes. <br>
<br>Note that <span class="name">memory.LeakPtrValChanged mentioned checking both malloc/free and new/delete, but this patch only considers malloc/free.<br><br>Please let me know if the attached patch is appropriate, or if it is missing something or there is another solution which may be a better fit.<br>
<br>- Branden<br></span></span><span class="name"><br></span>
<span><leakPtrValChanged.patch></span>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits<br></blockquote></div><br></body></html>