[cfe-dev] [Analyzer] Tips on how to fix PR22954 ? (false positive memory leak warning)

[Anton Yartsev]

Perhaps the ideal solution is to model "memcpy" properly (similar to 
assignment?). As you correctly noticed currently we just invalidate the 
destination buffer in the CString checker and the invalidation worker 
invalidates the whole struct (do not exactly know the reason for this).
While experimented wrote a patch (attached) that fixes the issue by 
adding a trait for the struct region that prevents the region from being 
invalidated. The solution does not cause regressions in the clang 
testsuite. Do not know if the solution is acceptable as a short term 
fix. Please review!

> Ping !
> Adding analyzer experts to cc.
>
> Regards,
>
> Pierre Gousseau
> SN Systems - Sony Computer Entertainment
>
> On 2 July 2015 at 09:06, Pierre Gousseau <pierregousseau14 at gmail.com 
> <mailto:pierregousseau14 at gmail.com>> wrote:
>
>     Dear All,
>
>     I have been looking into PR22954 which has been kindly raised by
>     krzystof at https://llvm.org/bugs/show_bug.cgi?id=22954 and being
>     new to this area of Clang I would appreciate any tips on how to
>     fix it.
>
>     To me the root of the issue seems to originate from the CString
>     checker as it performs invalidation of the destination buffer.
>     Given the snippet below:
>     -----------------
>     struct aa { char *s; char data[32];};
>     ...
>     a.s = malloc(nbytes);
>     memcpy(a.data, source, len);
>     ...
>     -----------------
>     As the CString checker handles the memcpy call, it requests the
>     invalidation of the 'a.data' region. But the invalidation worker
>     seems to consider that the whole memory region of 'a' has to be
>     invalidated. The Malloc checker is not made aware of this causing
>     the false positive.
>
>     It seems a short term fix could be to detect this specific case
>     and have the CString checker notify the Malloc checker that it
>     should stop tracking 'a.s'.
>     However this solution would reduce the number of genuine defects
>     detected.
>
>     So I would be grateful if someone could give some hints on how to
>     provide the right solution.
>
>     Regards,
>
>     Pierre Gousseau
>     SN Systems - Sony Computer Entertainment
>
>


-- 
Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150717/274ce514/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PR22954.patch
Type: text/x-diff
Size: 1470 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150717/274ce514/attachment.patch>