On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <dmalc...@redhat.com>
> wrote:
>
> > 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.
> >
> > Hi, thanks for the effort, sorry for the typo. I now know about the
> godbolt.org and it is certainly useful.
>
> > 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
> >
> > That's something new. I also didn't know that. I believe we can
> > shift our
> minimal example to just func() and remove main().
Yes - simpler is better with such examples.
(Occasionally it's helpful to have "main" so that the resulting code
can be executed - especially under valgrind, as a check that something
really is leaking - but a simpler reproducer is usually best when
debugging)
[...snip...]
> > I think an implementation of exception-handling would look somewhat
> > similar.
> >
> > Thanks, for all the references to the code. I am new to GCC, so
> > apologies
> if I am a bit slow in understanding. I am trying to run and go
> through all
> the references that you gave me.
Sorry if I'm overwhelming you with too much at once...
...and here's yet more information!
I wrote this guide to getting started with hacking on GCC, aimed at
newcomers to the project:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/
and in particular you may find the guide to debugging GCC useful:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
FWIW I like to use
-fanalyzer-dump-stderr
when stepping through the analyzer in gdb, so that I can put
breakpoints on what I'm interested in, but also have a log of the
activity that happened between the breakpoints.
> > > Please, let me know your thoughts on this.
> >
> > Looks like you're making a great start.
> >
> Thanks for the feedback. In parallel, can I start working on the
> Gsoc
> proposal as well?
Please do work on the formal proposal - without it we can't accept you
as a GSoC student. The window for submitting proposals opened
yesterday, and I believe it closes in a couple of weeks, and you need
to do that, so any experimentation you do now should really just be in
support of writing a good proposal. It would be a shame to not have a
good prospective candidate because they didn't allow enough time to do
the proper GSoC paperwork before the deadline.
> I hope, we can get suggestions from the gcc community as
> well once the things are written properly in a document.
Indeed
Hope this is constructive
Dave
[...snip...]
