> On 30-Mar-2021, at 7:27 PM, David Malcolm <dmalc...@redhat.com> wrote:

>> This gave rise to some questions
>> 
>> 1. why does the analyzer make exceptions with the main() function ?
> 
> The user's attention is important - we don't want to spam the user with
> unnecessary reports if we can help it.

make sense. 

——

After fiddling around with a lot of C codes, I switched to C++ programs  
in-order to find how exactly the analyzer doesn’t understand exception handling 
and more interestingly calls to virtual functions ( which I am thinking to work 
on this summer ). 

It was comparatively harder to find such an example where it would fail as 
looks like gcc do amazingly nice job at devirtualising the function calls ( 
even with -O0 option ) but finally after a lot of attempts and reading online 
about devirtualisation, I found this particular example where the analyzer 
generates a false positive

#include <cstdlib>

struct A
{
    virtual int foo (void) 
    {
        return 42;
    }
};

struct B: public A
{
    int *ptr;
    void alloc ()
    {
        ptr = (int*)malloc(sizeof(int));
    }
        int foo (void) 
    { 
        free(ptr);
        return 0;
    }
};

int test()
{
    struct B b, *bptr=&b;
    b.alloc();
    bptr->foo();
    return bptr->foo();
}

int main()
{
    test();
}

working link of the above code (https://godbolt.org/z/n17WK4MxG 
<https://godbolt.org/z/n17WK4MxG>)

here as the analyzer doesn’t understand the call to virtual function, wasn’t 
able to locate a double free in the program which was found at runtime.

so I went through it’s exploded graph to see how exactly is this being 
processed. And from the looks of things the anayzer doesn’t understood the 
function call which according to me was the following part in gimple 
representation :

1 = bptr_8->D.3795._vptr.A;
 _2 = *_1;
OBJ_TYPE_REF(_2;(struct B)bptr_8->0) (bptr_8)

after scanning the source-code a bit i found out that such calls were being 
processed by "region_model::handle_unrecognized_call()” where it just keeps 
track of reachable states from that node.

——

Questions 

1. The link to the bug tracker for vfunc() [ 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114> ] says that for vfuncs() 
to be understood by anayzer, it ought to be able to devirtualize calls, but is 
it possible to devirtualise all the calls ? what if it is random or depends on 
user input ?

2. Even though analyzer didn’t understood calls to virtual function, it didn’t 
gave warning about a memory leak either which according to it, should exist if 
the functions were never called to deallocate the pointer ( after exploded node 
152 and 118, the state of malloc changes automatically ) ?

sorry if I am asking a lot of questions.

Thank you

- Ankur

Reply via email to