[cfe-dev] How does Clang Static Analyzer deal with malloc()?

[Arthur Yoo]

For *malloc()* problem, I have done some tests with the code below, which
is lightly modified based on the testcase from commit r158136.

int CMPRegionHeapToStack_modified () {

    int x = 0;

    int *x1 = malloc(8);

    int *x2 = &x;

*x2 = 3;

*x1 = 2;

    free(x1);

    return x;

}

When evaluating the write operation in ‘**x2 = 3;*’, I could got the
MemRegion of *x*, which is actually the MemRegion referred by *x2*. Then I
tried to get the super region of *x*. Consequently, I got the
*StackLocalsSapaceRegion,
*which conforms to my expectation. However, then I tried to do the same
things on ‘**x1 = 2*’ and *x1*. Firstly, I got *element{SymRegion{conj_$2{void
*}},0 S32b,int}*, which is the MemRegion referred by *x1* via *malloc()*.
Then I tried to get the super region of *SymRegion{conj_$2{void *}}. *What
I got is *UnkonwnSpaceRegion*. In my expectation, the result should be
*HeapSapceRegion*. In a nutshell, from the result, it seems that Static
Analyzer thought the parent of *SymRegion{conj_$2{void *}}* (referred by
*x1* via *malloc()*) is *UnkonwnSpaceRegion,* rather than* HeapSapceRegion.
*I don’t know why…





For the problem of *isInSystemHeader()* of CallEvent, I did this in the
checkPreCall(). Here is my code.

void MyChecker::checkPreCall(const CallEvent &Call, CheckerContext &C)
const {

       if(Call.isInSystemHeader()) {

       return; /* Ignore the system function calls */

}



/* Here is the code for the function calls not in the system header */

       std::cout << “Call.isInSystemHeader() is false\n”;

……

}

My test code contains some system function calls, such as *scanf(),
printf(), malloc()* and etc. When evaluating these function calls, the
checkPreCall() did’t return directly. On the contrary, the checker
continued to do the things that for non-system function calls. So it
doesn’t work and confused me. It seems that Static Analyzer cannot tell
whether a function call is in system header rightly with
*isInSystemHeader()*. I did this test on the LLVM/Clang 3.4.2 downloaded
from http://llvm.org/releases/download.html#3.4.2.


2014-06-24 4:52 GMT+08:00 Anna Zaks <ganna at apple.com>:

>
> On Jun 23, 2014, at 9:37 AM, Arthur Yoo <phjy007 at gmail.com> wrote:
>
> Hi all,
>
> I have some problem on the result of Clang Static Analyzer dealing with
> malloc().  Here is the simple test code, which I tried:
>
> int *pi;
>
> pi = (int *)malloc(sizeof(int));
>
> *pi = 8;
>
> free(pi);
>
>
> The *pi* is a pointer variable. After malloc() being called, *pi* points
> to an object which is located on the heap. However, in the Clang Static
> Analyzer, I found that after malloc() being called, *pi* pointed to*
> element{SymRegion{conj_$2{void *}},0 S32b,int}*. Then I tried to get the
> super region of *SymRegion{conj_$2{void *}}. *What confused me is that,
> the super region of *SymRegion{conj_$2{void *}}* was *UnkonwnSpaceRegion*.
> I thought its super region should be HeapSapceRegion, because I use
> malloc() for dynamic memory allocation in the code. But now I get the
> different result. So I wonder how does Static Analyzer deal with malloc()?
> Does Static Analyzer regard malloc() as an ordinary function which returns
> an pointer?
>
> You can find out more about how heap region is used and constructed from
> commit r158136. The SymRegion should have heapRegion() as it's parent.
> Maybe the printing is off?
>
>
>
> What’s more, I have a question on the method* isInSystemHeader() *of
> CallEvent. I use it to test whether the CallEvent is an system function
> call, such as *scanf(), printf()* and etc. But it seems it does work. It
> seems that Static Analyzer cannot tell whether a function call is in system
> header rightly. And my Clang version is 3.5.
>
>
>
> It should work. How are you testing this?
>
> Thanks a lot.
>
> --
> Best regards,
> Arthur Yoo
>  _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>


-- 
Best regards,
Arthur Yoo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140624/14456f49/attachment.html>