On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> Hi, I have tried the following examples with the fanalyzer option in
> g++.
>
> 1 (a)
> void myFunction()
> {
> char *p =new char;
> }
> int main()
> {
> func();
> return 0;
> }
BTW, are you familiar with Compiler Explorer (godbolt.org)? It's very
handy for testing small snippets of code on different compilers and
different compiler versions. Though I don't know how long the URLs are
good for (in terms of how long code is cached for)
Fixing up the name of the called function to "func":
https://godbolt.org/z/TnM6n4xGc
I get the leak report, as per RFE 94355. This warning looks correct,
in that p does indeed leak.
I should mention that the analyzer has some special-casing for "main",
in that the user might not care about one-time leaks that occur within
"main", or something only called directly by it; this doesn't seem to
be the case here. If I remove the implementation to main, the analyzer
still correctly complains about the leak:
https://godbolt.org/z/zhK4vW6G8
<source>: In function 'void func()':
<source>:4:1: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
4 | }
| ^
'void func()': events 1-2
|
| 3 | char *p =new char;
| | ^~~~
| | |
| | (1) allocated here
| 4 | }
| | ~
| | |
| | (2) 'p' leaks here; was allocated at (1)
|
> 1(b)
> void myFunction()
> {
> try {
> char *p = new char;
> throw p;
> }
> catch(...) {
> }
> }
> int main()
> {
> myFunction();
> return 0;
> }
> In 1(a), there is no exception handling. When I ran `cc1plus`, a
> memory
> leak was reported as shown in bug #94355.
> In 1(b), there is a use of exception handling. When I ran cc1plus`,
> no
> memory leaks were detected. I believe there should be one. Can you
> please
> confirm from your side as well?
I too am seeing no diagnostics on 1(b).
> As you said all the calls to try, catch and
> throw got converted to _cxa prefixed functions.
-fdump-ipa-analyzer=stderr shows the _cxa-prefixed functions:
https://godbolt.org/z/YMa9dE6aM
> I am trying to find the
> places where the corresponding checks can be placed for the analysis
> of
> exception handling in gimple IR.
Have a look at exploded_node::on_stmt in engine.cc; in particular, see
the GIMPLE_CALL case in the switch statement. Most of the the
analyzer's "knowledge" of the behaviors of specific functions is here,
or called from here.
The simpler cases are handled in the call to
m_region_model->on_call_pre
for functions which merely update state, which are implemented in
region-model-impl-calls.cc
Cases involving state machines (e.g. allocation) are handled in the:
sm.on_stmt
call torwards the bottom of the function.
But exception-handling is a special case, in that it affects control
flow. The closest thing to compare it to currently within the analyzer
is setjmp/longjmp, so it's worth stepping through how that is handled.
In particular, the real implementation of longjmp involves directly
updating the program counter, registers and stack, potentially popping
multiple stack frames. This is similar to what throwing an exception
does.
So I'd recommend looking at the analyzer's implementation of
setjmp/longjmp, the custom classes that I added to handle them, and
stepping through how exploded_node::on_stmt handles setjmp and longjmp
calls, and what the resulting exploded_graph looks like (-fdump-
analyzer-exploded-graph and -fdump-analyzer-supergraph), in that
special-cased edges have to be created that weren't in the original
CFGs or callgraph (for the interprocedural case).
I think an implementation of exception-handling would look somewhat
similar.
> Please, let me know your thoughts on this.
Looks like you're making a great start.
Hope this is helpful
Dave
> On Fri, Mar 26, 2021 at 12:48 AM David Malcolm <dmalc...@redhat.com>
> wrote:
>
> > On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > > Hi all,
> > > I am an undergraduate student in AMU, Aligarh. I am interested in
> > > the
> > > project* `Extend the static analysis pass`. *I have followed
> > > this(
> > > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and
> > > been
> > > able to
> > > successfully build and successfully ran and pass the test suite
> > > for C
> > > and
> > > C++.
> > >
> > > I found this sub-project `C++ support (new/delete checking,
> > > exceptions,
> > > etc)` interesting and may be the conservative code for this can
> > > be
> > > made
> > > along the lines of malloc/free implementation in C. I found here(
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some
> > > part of
> > > it
> > > has already been implemented . I would like to expand it further
> > > and
> > > learn
> > > about it, maybe start with writing some test cases, please let me
> > > know.
> > >
> > > Further, I am inclined on this(
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know
> > > if
> > > it is
> > > still available.
> > >
> > > Looking forward to hearing from you guys.
> > > Thanks,
> > > Saloni Garg
> >
> > Hi!
> >
> > I'm the author/maintainer of the static analysis pass, and would be
> > the
> > mentor for any GSoC project(s) involving it.
> >
> > I've already implemented most of the new/delete checking in GCC 11;
> > the
> > big missing component there is exception-handling.
> >
> > Implementing exception-handling in the analyzer could make a good
> > GSoC
> > project: it's non-trivial, but hopefully doable in one summer. I
> > see
> > you've already seen bug 97111, and there are some links in that bug
> > to
> > resources. Given that the analyzer runs on the gimple-ssa
> > representation, by the time it sees the code, much of the
> > exception-
> > handling has already been translated into calls to various __cxa_-
> > prefixed functions in the C++ runtime, so part of the work would
> > involve "teaching" the analyzer about those functions. One way to
> > make
> > a start on this would be to create a collection of trivial C++
> > examples
> > that use exceptions, and then look at analyzer dumps to see what IR
> > is
> > being "seen" by the analyzer for the various constructs. (I
> > actually
> > started this a long time ago and have a very crude barely-working
> > prototype, but it was just the start, and I've forgotten almost all
> > of
> > it...)
> >
> > Hope this is helpful
> > Dave
> >
> >
> >
