<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">Hi Artem,<br><br></div><div class="gmail_default">Thank you very much for the help and explanation.</div></div><div class="gmail_default" style="font-size:small">I have created a draft for my GSoC proposal and I am sharing the link with this mail. <br>Could you please have a look and let me know the feedback for the draft proposal?<br>Draft proposal: <a href="https://docs.google.com/document/d/1HORDm6cq3YolYTPGFLCF5gLjIyf6bygHeWzG1kd1T-g/edit?usp=sharing">https://docs.google.com/document/d/1HORDm6cq3YolYTPGFLCF5gLjIyf6bygHeWzG1kd1T-g/edit?usp=sharing</a><br></div><div><div dir="ltr" data-smartmail="gmail_signature"><br></div><div dir="ltr" data-smartmail="gmail_signature">---<br><span class="gmail_default" style="font-size:small">Thanks & </span>Regards,<br><font face="'courier new', monospace">Nithin</font><br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 5:18 PM Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com" target="_blank">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"><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->() 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 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 aware <br>
that the raw pointer is deleted, so it'll keep hosting the pointer 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>
<span class="gmail_default" style="font-size:small"></span><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 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 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 smart <br>
pointer becomes null, but also all the situations when the smart 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 another <br>
possible solution. The annoying limitation that we run into here 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 field) of a <br>
bigger object. This basically means that we have to understand how does <br>
the smart pointer work internally (which field corresponds to 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 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 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>>> 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 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>>> wrote:<br>
><br>
> Hey!<br>
><br>
> Welcome. Let's see.<br>
><br>
> Nullability checker isn't the one that you're looking 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 provided<br>
> through which the programmer can tell the analyzer which<br>
> variables /<br>
> functions may or may not hold / produce null pointers, and the<br>
> analyzer<br>
> checks whether it makes sense how these nullable and 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 crashes in<br>
> Objective-C apps that pass a lot of pointers around across many<br>
> user-defined functions.<br>
><br>
> The proposed GSoC project is of a different nature: we want to<br>
> teach the<br>
> static analyzer about a very specific C++ API, but we 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 finds<br>
> *some*<br>
> null smart pointer dereferences, given that they're 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 vector.end().<br>
> It's the<br>
> closest thing to what you'll be implementing, but its 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 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 it, the<br>
> next step<br>
> is to discuss here (in this mailing list) what is the best way to<br>
> implement the checker. The ultimate outcome of this 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* 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 particularly<br>
> > interested in the project idea "Find null smart pointer<br>
> dereferences<br>
> > with the Static Analyzer". I am doing my masters in computer<br>
> science<br>
> > and interested in program analysis and verification. I thought<br>
> > GSoC2020 will be a wonderful opportunity to learn more about<br>
> Clang<br>
> > Static Analyzer and contribute.<br>
> ><br>
> ><br>
> > I have started reading about smart pointers in C++ to 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 analysis of C<br>
> programs"<br>
> > to get some theoretical background. I also started looking into<br>
> > NullabilityChecker.cpp<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>
> > <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>
</blockquote></div></div>