[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
Thu Mar 26 16:45:22 PDT 2020
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> 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>> 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>> 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>
> > > 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/20200327/e8cbab70/attachment-0001.html>
More information about the cfe-dev
mailing list