static analysis inlining varargs functions

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?

Thanks,

Bob Kuo

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?

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.)

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?

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?

Add another function that is the same as this one except it is not varargs and see if the error is still reported.

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?

No, not for the MallocChecker you are using.

We have an experimental MallocOptimistic checker that assumes that all functions that free memory are annotated. By default, it will assume that if you pass a pointer to a function, the function will not free it. If you wanted to use that checker, you would need to annotate all functions in your codebase with these annotations. I don’t think may users would be interested in this workflow and this is why the checker is experimental.