[cfe-dev] static analysis inlining varargs functions

[Bob Kuo]

On 4/1/15, 1:50 PM, "Anna Zaks" <ganna at apple.com> wrote:



>
>
>On Mar 17, 2015, at 1:21 PM, Bob Kuo <Bob.Kuo at riverbed.com> wrote:
>
>Hello clang developers,
>
>
>We recently found a memory leak at work we were not freeing allocated 
>memory returned by the standard C string strdup() function.  I ran the 
>static analyzer against a version of the code with the defect and it 
>didn't detect a memory leak.  When
> I reduced the code to a simpler test case the static analyzer correctly 
>identified the leak.  After a few iterations I found that the culprit was 
>a varargs function where the variable that held a reference to the 
>allocated memory was a parameter.  With the
> call to the varargs function commented out, the static analyzer 
>identified the leak.  With the call to the varargs function no warning 
>was produced. 
>
>
>Is this a design decision or inherent limit in the static analyzer?  Is 
>this a known issue?  I didn't see any bugs in the tracker.  Should I file 
>a bug?
>
>
>
>
>
>
>
>I am not sure if it is related to the function being varargs or just 
>passing the reference to a function the analyzer does not see. Can you 
>check that?

Apologies for my ignorance, but how would I do that?

>
>
>When a pointer to allocated memory is passed to a function that the 
>analyzer does not see, the analyzer assumes that that function could free 
>it. (This is by design to reduce the number of false positives.)

For functions that the static analyzer can't see - perhaps it is in 
another translation unit - is it possible to tag that function or 
parameters to that function with some kind of attribute to indicate if the 
memory is consumed/freed?

>
>
>Thanks,
>
>
>Bob Kuo
>
>
>_______________________________________________
>cfe-dev mailing list
>cfe-dev at cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
>