[cfe-dev] [analyzer] MallocChecker & checker dependencies

Fri Mar 16 12:22:34 PDT 2018

Hello guys,

And thanks for your attention

Aleksei,

Could you share your ideas of checker design? It is possible that problems
> you met can be solved in different (maybe even better) way if we know the
> whole picture.
>

As I said, I'm interested in improving current state of dynamic memory
modeling. Especially stuff related to smart pointers (e.g. shared, unique)
which also mentioned in list of potential checkers as smartptr.SmartPtrInit
<https://clang-analyzer.llvm.org/potential_checkers.html>

You can see an example of how state trait is exported in
> GenericTaintChecker or MPIChecker. Generally, you just create a named
> ProgramStateTrait in the header.
>

Briefly looked at MPITypes.h. Does it mean we should move RegionState to
separate file and register it via Traits in the same manner to make it
avaliable from other checkers (not other TU as mentioned in
ento::mpi::RequestMap)?

Artem,

you need to keep all of this in mind when writing a checker.
>

Sure, but on the other hand I think it's possible to implement and improve
modeling of various API calls' effects step-by-step. Let's say, it case of
SmartPtrInit checker mentioned before the bare minimum would be modeling of
construction (and destruction to avoid leak report from existing related
checkers).

which is why the few experimental C++ checkers that we currently have
> required heavy hacks to become possible. But for now you'd rather keep an
> eye on these problems.
>

Does it mean it's better to wait a bit for Core improvements from main
contributors? Does it make sense to make an efforts to implement
SmartPtrItnit checker in current state of things?

Thanks in advance and regards,
Alexey K

2018-03-16 21:47 GMT+03:00 Artem Dergachev <noqnoqneo at gmail.com>:

> Dynamic memory management is pretty much done at this point - we have very
> good support for malloc()-like stuff and reasonably good support for
> operator new() (support for operator new[]() is currently missing because
> it requires calling an indefinite number of constructors which is not yet
> implemented). There is also a known issue with custom operator new(...)
> returning null pointers - in this case we should not be calling the
> constructor but for now we evaluate the constructor conservatively.
>
> Your real problem will be managing smart pointers themselves because they
> are C++ objects that have a myriad of methods, they can be copied, moved,
> assigned, move-assigned, they destroyed, they lifetime-extended, you need
> to keep all of this in mind when writing a checker. This is slowly getting
> easier because i'm currently working on that, but until recently it wasn't
> working correctly in the core, let alone checkers, which is why the few
> experimental C++ checkers that we currently have required heavy hacks to
> become possible. But for now you'd rather keep an eye on these problems.
>
> On 16/03/2018 3:57 AM, Aleksei Sidorin via cfe-dev wrote:
>
>> Hi Alexey!
>>
>> Could you share your ideas of checker design? It is possible that
>> problems you met can be solved in different (maybe even better) way if we
>> know the whole picture.
>> Regarding your questions, you can find some answers below.
>>
>> 1. a) The first way for checker communication is to share their program
>> state trait. You can see an example of how state trait is exported in
>> GenericTaintChecker or MPIChecker. Generally, you just create a named
>> ProgramStateTrait in the header. You can take a look at TaintManager.h and
>> MPITypes.h and how they are used.
>> b) To set a dependency from another checker, you can just register it
>> while registering your checker. An example can be found in MallocChecker
>> where register$Checker also calls registerCStringCheckerBasic to register a
>> checker it depends on.
>> As you pointed, inter-checker communication can become a source of some
>> problems. Most of them are discussed in this conversation:
>> http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Des
>> ign-idea-separate-modelling-from-checking-td4059122.html
>>
>> 2. I think there is nothing bad in sharing RegionState across checkers in
>> the way shown in 1a.
>>
>> 3. Artem Dergachev has done some excellent work on improvement of
>> operator 'new' processing in CSA engine. Regarding checkers, I can see some
>> on https://clang-analyzer.llvm.org/potential_checkers.html: for example,
>> undefbehavior.AutoptrsOwnSameObj. You can search this list to find more.
>>
>>
>> 15.03.2018 23:54, Alexey Knyshev via cfe-dev пишет:
>>
>>> Hi there!
>>>
>>> While thinking about how it would be possible to implement various smart
>>> ptr related checkers I tried to review current state of MallocChecker and
>>> came up with that it would be great to have RegionState info available to
>>> other checkers. Could you please share your points of view and comments on
>>> the following statements / questions:
>>>
>>> 1. Is there any right way for chaining checkers? How they are expected
>>> to communicate between each other (excluding generation of nodes /
>>> ProgramStates). I've heard that there are couple of problems caused by
>>> inlining functions, constructors / descructors.
>>> 2. What do you think about moving RegionState to the Core of CSA or
>>> providing optional extended info in MemRegion about the source of such
>>> region (new opearator / array new, malloc, alloca, etc). So it would be
>>> available to all checkers.
>>> 3. Is there any roadmap for CSA and especially for dynamic memory
>>> management modeling & related checkers?
>>>
>>> Regards, Alexey K
>>>
>>> --
>>> linkedin.com/profile <https://www.linkedin.com/prof
>>> ile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw>
>>>
>>> github.com/alexeyknyshev <http://github.com/alexeyknyshev>
>>> bitbucket.org/alexeyknyshev <https://bitbucket.org/alexeyknyshev/>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>>
>> --
>> Best regards,
>> Aleksei Sidorin,
>> SRR, Samsung Electronics
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>

-- 
linkedin.com/profile
<https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw>

github.com/alexeyknyshev
bitbucket.org/alexeyknyshev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180316/70855471/attachment.html>