[cfe-dev] [GSoC] Interested in idea: "Find null smart pointer dereferences with the Static Analyzer"
Nithin Vadukkumchery Rajendrakumar via cfe-dev
cfe-dev at lists.llvm.org
Mon Mar 30 14:23:27 PDT 2020
Hi Artem,
I have uploaded the final proposal.
Once again, thank you very much for your help and support.
----
Regards,
Nithin.VR
On Mon, Mar 30, 2020 at 8:33 PM Artem Dergachev <noqnoqneo at gmail.com> wrote:
> The proposal looks good to me with your latest fixes! I encourage you to
> upload it to the GSoC website; their deadline is tomorrow. Thanks again
> for your interest :)
>
> On 3/27/20 2:45 AM, Nithin Vadukkumchery Rajendrakumar wrote:
> > Hi Artem,
> >
> > Thank you very much for the help and explanation.
> > I have created a draft for my GSoC proposal and I am sharing the link
> > with this mail.
> > Could you please have a look and let me know the feedback for the
> > draft proposal?
> > Draft proposal:
> >
> https://docs.google.com/document/d/1HORDm6cq3YolYTPGFLCF5gLjIyf6bygHeWzG1kd1T-g/edit?usp=sharing
> >
> > ---
> > Thanks & Regards,
> > Nithin
> >
> >
> > On Mon, Mar 23, 2020 at 5:18 PM Artem Dergachev <noqnoqneo at gmail.com
> > <mailto:noqnoqneo at gmail.com>> wrote:
> >
> >
> >
> > On 3/20/20 7:56 PM, Nithin Vadukkumchery Rajendrakumar wrote:
> > > Hello Artem,
> > >
> > > I went through the checkers you suggested. I found this project
> > > seems interesting to me and I got a very basic idea about it.
> > >
> > > I tried to find out few cases where unique_ptr::operator->()
> > returns
> > > null apart from default constructed unique_ptr.
> > > *Case 1: *Use of std::move on std::unique_ptr
> > > It seems its already covered in the MoveChecker.
> > > *Case 2:* Use after calling release() on std::unique_ptr
> > > When I ran the analyzer for this scenario, it did produce any
> > warnings
> > > *Case 3: *Use up.reset() or up.reset(nullptr)
> > > Similar to release() case it seems this case also not covered.
> > > *Case 4:* Get raw pointer via std::unique_ptr.get() then delete
> > > I am not sure about this case. It seems user explicitly trying to
> > > break the code.
> >
> > No-no, that's not how C++ works :) the smart pointer wouldn't be
> > aware
> > that the raw pointer is deleted, so it'll keep hosting the pointer
> > and
> > cause a use-after-free instead. We could warn about those as well
> > though; it might turn out to be an easy addition once you get the
> > checker running.
> >
> > > *Case 5:* Use after swap(std::unique_ptr, null)
> > > In case we swap a std::unique_ptr with another std::unique_ptr with
> > > pointing null.
> > >
> > > I am guessing the list is not complete and this will be a first
> > task,
> > > to figure out all possible cases.
> > > And some what same we have to come up with for other smart
> pointers.
> > >
> > > Regarding the implementation part, similar to move checker we
> > have to
> > > keep a map for memory region and state (whether it is null or not).
> > > States should be updated based on the changes in MemRegion. I was
> > > wondering is this the right way? (I know I still have to figure out
> > > lot of details regarding concrete implementations)
> >
> > Yup, I think that's the most solid and straightforward solution. Note
> > that you will have to not only enumerate all situations when the
> > smart
> > pointer becomes null, but also all the situations when the smart
> > pointer
> > becomes non-null.
> >
> > > In case of default-constructed std::unique_ptr object, why can't we
> > > get symbolic value as null and do a check same as what we are doing
> > > for raw pointer?
> > > Is it because some limitations on tracking the symbolic values
> > > of std::unique_ptr objects?
> >
> > Manipulating symbolic values inside the smart pointer is indeed
> > another
> > possible solution. The annoying limitation that we run into here
> > is that
> > our memory model ("RegionStore") doesn't currently allow setting a
> > "default" binding to a whole object when it's a part (say, a
> > field) of a
> > bigger object. This basically means that we have to understand how
> > does
> > the smart pointer work internally (which field corresponds to
> > what) in
> > order to manipulate its symbolic value, which ties us to a specific
> > implementation of the C++ standard library. This might still work
> > for a
> > unique pointer which probably always has exactly one field, but for
> > shared pointers things get complicated.
> >
> > You can try to overcome this limitation of RegionStore if you're
> > eager
> > enough but that'll be challenging and potentially a lot of work. And
> > even if there wasn't this limitation, this approach isn't necessarily
> > much easier than the first approach.
> >
> > > ----
> > > Thanks & Regards,
> > > Nithin
> > >
> > >
> > > On Tue, Mar 10, 2020 at 1:13 AM Nithin Vadukkumchery Rajendrakumar
> > > <vrnithinkumar at gmail.com <mailto:vrnithinkumar at gmail.com>
> > <mailto:vrnithinkumar at gmail.com <mailto:vrnithinkumar at gmail.com>>>
> > wrote:
> > >
> > > Hi Artem,
> > >
> > > Thank you very much for this detailed information and help.
> > > I will checkout the existing checkers you mentioned and try
> > to get
> > > a better understanding of the problem.
> > >
> > > ----
> > > Regards,
> > > Nithin.VR
> > >
> > >
> > > On Mon, Mar 9, 2020 at 2:30 AM Artem Dergachev
> > > <noqnoqneo at gmail.com <mailto:noqnoqneo at gmail.com>
> > <mailto:noqnoqneo at gmail.com <mailto:noqnoqneo at gmail.com>>> wrote:
> > >
> > > Hey!
> > >
> > > Welcome. Let's see.
> > >
> > > Nullability checker isn't the one that you're looking
> > for. It's a
> > > different beast that governs hunt for null dereferences via
> > > so-called
> > > "nullability annotations". Like, a language extension is
> > provided
> > > through which the programmer can tell the analyzer which
> > > variables /
> > > functions may or may not hold / produce null pointers,
> > and the
> > > analyzer
> > > checks whether it makes sense how these nullable and
> > non-null
> > > values
> > > propagate from one function to another. So it's the same
> > > problem but a
> > > different technique. It is targeted mostly at finding
> > crashes in
> > > Objective-C apps that pass a lot of pointers around
> > across many
> > > user-defined functions.
> > >
> > > The proposed GSoC project is of a different nature: we
> > want to
> > > teach the
> > > static analyzer about a very specific C++ API, but we
> > want to
> > > teach it
> > > much more thoroughly. It's not enough to know that
> > > std::unique_ptr::operator->() may occasionally return a
> null
> > > pointer;
> > > we'd much rather know when exactly does it return a null
> > > pointer (eg.,
> > > if the smart pointer is freshly default-constructed).
> > >
> > > If you want to study existing checkers, check out:
> > > - MoveChecker - the use-after-move checker which already
> > finds
> > > *some*
> > > null smart pointer dereferences, given that they're
> > guaranteed
> > > to be
> > > null after move.
> > > - SmartPtrChecker currently does almost nothing, but that's
> > > probably
> > > where you put your code into :)
> > > - IteratorChecker is a large ongoing pioneer project to
> find
> > > iterator
> > > and container related bugs such as dereferencing
> > vector.end().
> > > It's the
> > > closest thing to what you'll be implementing, but its
> > handling
> > > of C++
> > > objects is outdated and overly complicated because some new
> > > facilities
> > > for C++ support (mostly the ones explained in the second
> > half of
> > > https://www.youtube.com/watch?v=4n3l-ZcDJNY) weren't in place
> > > yet when
> > > it all started.
> > >
> > > Once you understand the project a bit better and like
> > it, the
> > > next step
> > > is to discuss here (in this mailing list) what is the
> > best way to
> > > implement the checker. The ultimate outcome of this
> > discussion
> > > will be a
> > > so-called "GSoC proposal". It's a few pages of text that
> you
> > > write, post
> > > here for more discussion, and eventually upload to the GSoC
> > > website.
> > > According to the GSoC timeline, the proposal should be
> > > submitted by the
> > > end of March. The proposal summarizes how *you*
> > understand the
> > > project
> > > and how *you* plan to tackle it during the summer.
> > >
> > > Good luck on your GSoC path!
> > > Artem.
> > >
> > >
> > > On 3/7/20 3:40 PM, Nithin Vadukkumchery Rajendrakumar via
> > > cfe-dev wrote:
> > > >
> > > > Greetings,
> > > >
> > > >
> > > > I am interested to participate in GSoC 2020. I am
> > particularly
> > > > interested in the project idea "Find null smart pointer
> > > dereferences
> > > > with the Static Analyzer". I am doing my masters in
> > computer
> > > science
> > > > and interested in program analysis and verification. I
> > thought
> > > > GSoC2020 will be a wonderful opportunity to learn more
> > about
> > > Clang
> > > > Static Analyzer and contribute.
> > > >
> > > >
> > > > I have started reading about smart pointers in C++ to
> > get a
> > > good grasp
> > > > of the concepts. Also, has some experience in
> implementing
> > > Clang
> > > > Static Analyzer simple checks(similar to
> > > SimpleStreamChecker) from the
> > > > tutorials. I read through few available tutorials and
> have
> > > some basic
> > > > idea about Control Flow Graph, Exploded Graph and
> Symbolic
> > > Values. I
> > > > have read the paper "A memory model for static
> > analysis of C
> > > programs"
> > > > to get some theoretical background. I also started
> > looking into
> > > > NullabilityChecker.cpp
> > > >
> > >
> > <
> https://github.com/llvm/llvm-project/blob/master/clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
> > to
> > >
> > > > understand the codebase.
> > > >
> > > > I would like to know is this the right place to look?
> > > >
> > > > Could anyone please help me on what should I do next?
> > > >
> > > > ----
> > > > Thanks & Regards,
> > > > Nithin
> > > >
> > > > _______________________________________________
> > > > cfe-dev mailing list
> > > > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> > <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200330/8082b7f5/attachment-0001.html>
More information about the cfe-dev
mailing list