> 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