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

Fri Mar 16 12:30:02 PDT 2018

Sorry, accidentally removed part of message before sending.

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.
>

I'm currently have no clear idea how to implement it in the "right manner".
But first of all I would aim to track the origin (malloc, new, new [], etc)
of SVal and check if Deleter is the expected corresponding way to
deallocate such SVal.

Regards, Alexey K

2018-03-16 22:22 GMT+03:00 Alexey Knyshev <alexey.knyshev at gmail.com>:

> 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
>

-- 
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/15406c6c/attachment.html>