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