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

[Artem Dergachev via cfe-dev]

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-Design-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/profile/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