History log of /llvm-project/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp (Results 76 – 100 of 397)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 72210ce7 24-May-2020 Simon Pilgrim <llvm-dev@redking.me.uk>

Fix Wdocumentation warnings after argument renaming. NFC.


# 1d393eac 20-May-2020 Kirstóf Umann <dkszelethus@gmail.com>

[analyzer] Fix a null FunctionDecl dereference bug after D75432


# 392222dd 25-Feb-2020 Kristóf Umann <dkszelethus@gmail.com>

[analyzer][NFC][MallocChecker] Convert many parameters into CallEvent

Exactly what it says on the tin! This is clearly not the end of the road in this
direction, the parameters could be merged far m

[analyzer][NFC][MallocChecker] Convert many parameters into CallEvent

Exactly what it says on the tin! This is clearly not the end of the road in this
direction, the parameters could be merged far more with the use of CallEvent or
a better value type in the CallDescriptionMap, but this was shockingly difficult
enough on its own. I expect that simplifying the file further will be far easier
moving forward.

The end goal is to research how we could create a more mature checker
interaction infrastructure for more complicated C++ modeling, and I'm pretty
sure that being able successfully split up our giants is the first step in this
direction.

Differential Revision: https://reviews.llvm.org/D75432

show more ...


# f2be30de 01-Mar-2020 Kirstóf Umann <dkszelethus@gmail.com>

[analyzer][NFC] Merge checkNewAllocator's paramaters into CXXAllocatorCall

Party based on this thread:
http://lists.llvm.org/pipermail/cfe-dev/2020-February/064754.html.

This patch merges two of CX

[analyzer][NFC] Merge checkNewAllocator's paramaters into CXXAllocatorCall

Party based on this thread:
http://lists.llvm.org/pipermail/cfe-dev/2020-February/064754.html.

This patch merges two of CXXAllocatorCall's parameters, so that we are able to
supply a CallEvent object to check::NewAllocatorCall (see the description of
D75430 to see why this would be great).

One of the things mentioned by @NoQ was the following:

I think at this point we might actually do a good job sorting out this
check::NewAllocator issue because we have a "separate" "Environment" to hold
the other SVal, which is "objects under construction"! - so we should probably
simply teach CXXAllocatorCall to extract the value from the
objects-under-construction trait of the program state and we're good.

I had MallocChecker in my crosshair for now, so I admittedly threw together
something as a proof of concept. Now that I know that this effort is worth
pursuing though, I'll happily look for a solution better then demonstrated in
this patch.

Differential Revision: https://reviews.llvm.org/D75431

show more ...


# 2e5e42d4 05-May-2020 Kirstóf Umann <dkszelethus@gmail.com>

[analyzer][MallocChecker] When modeling realloc-like functions, don't early return if the argument is symbolic

The very essence of MallocChecker lies in 2 overload sets: the FreeMemAux
functions and

[analyzer][MallocChecker] When modeling realloc-like functions, don't early return if the argument is symbolic

The very essence of MallocChecker lies in 2 overload sets: the FreeMemAux
functions and the MallocMemAux functions. The former houses most of the error
checking as well (aside from leaks), such as incorrect deallocation. There, we
check whether the argument's MemSpaceRegion is the heap or unknown, and if it
isn't, we know we encountered a bug (aside from a corner case patched by
@balazske in D76830), as specified by MEM34-C.

In ReallocMemAux, which really is the combination of FreeMemAux and
MallocMemAux, we incorrectly early returned if the memory argument of realloc is
non-symbolic. The problem is, one of the cases where this happens when we know
precisely what the region is, like an array, as demonstrated in the test file.
So, lets get rid of this false negative :^)

Side note, I dislike the warning message and the associated checker name, but
I'll address it in a later patch.

Differential Revision: https://reviews.llvm.org/D79415

show more ...


# 9d69072f 01-Mar-2020 Kirstóf Umann <dkszelethus@gmail.com>

[analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker

One of the pain points in simplifying MallocCheckers interface by gradually
changing to CallEvent is that a variety of C++ al

[analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker

One of the pain points in simplifying MallocCheckers interface by gradually
changing to CallEvent is that a variety of C++ allocation and deallocation
functionalities are modeled through preStmt<...> where CallEvent is unavailable,
and a single one of these callbacks can prevent a mass parameter change.

This patch introduces a new CallEvent, CXXDeallocatorCall, which happens after
preStmt<CXXDeleteExpr>, and can completely replace that callback as
demonstrated.

Differential Revision: https://reviews.llvm.org/D75430

show more ...


# 703a1b8c 26-Mar-2020 Louis Dionne <ldionne@apple.com>

[analyzer][MallocChecker][NFC] Split checkPostCall up, deploy CallDescriptionMap

Since its important to know whether a function frees memory (even if its a
reallocating function!), I used two CallDe

[analyzer][MallocChecker][NFC] Split checkPostCall up, deploy CallDescriptionMap

Since its important to know whether a function frees memory (even if its a
reallocating function!), I used two CallDescriptionMaps to merge all
CallDescriptions into it. MemFunctionInfoTy no longer makes sense, it may never
have, but for now, it would be more of a distraction then anything else.

Differential Revision: https://reviews.llvm.org/D68165

show more ...


# dcc04e09 30-Mar-2020 Balázs Kéri <1.int32@gmail.com>

[Analyzer][MallocChecker] No warning for kfree of ZERO_SIZE_PTR.

Summary:
The kernel kmalloc function may return a constant value ZERO_SIZE_PTR
if a zero-sized block is allocated. This special value

[Analyzer][MallocChecker] No warning for kfree of ZERO_SIZE_PTR.

Summary:
The kernel kmalloc function may return a constant value ZERO_SIZE_PTR
if a zero-sized block is allocated. This special value is allowed to
be passed to kfree and should produce no warning.

This is a simple version but should be no problem. The macro is always
detected independent of if this is a kernel source code or any other
code.

Reviewers: Szelethus, martong

Reviewed By: Szelethus, martong

Subscribers: rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D76830

show more ...


# bda3dd0d 27-Mar-2020 Kirstóf Umann <dkszelethus@gmail.com>

[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions

Some checkers may not only depend on language options but also analyzer options.
To make this possible this patc

[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions

Some checkers may not only depend on language options but also analyzer options.
To make this possible this patch changes the parameter of the shouldRegister*
function to CheckerManager to be able to query the analyzer options when
deciding whether the checker should be registered.

Differential Revision: https://reviews.llvm.org/D75271

show more ...


# 30a8b770 27-Mar-2020 Kirstóf Umann <dkszelethus@gmail.com>

[analyzer][MallocChecker] Fix that kfree only takes a single argument

Exactly what it says on the tin!

https://www.kernel.org/doc/htmldocs/kernel-api/API-kfree.html

Differential Revision: https://

[analyzer][MallocChecker] Fix that kfree only takes a single argument

Exactly what it says on the tin!

https://www.kernel.org/doc/htmldocs/kernel-api/API-kfree.html

Differential Revision: https://reviews.llvm.org/D76917

show more ...


Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# e5513336 20-Sep-2019 Kristóf Umann <dkszelethus@gmail.com>

[analyzer][MallocChecker][NFC] Change the use of IdentifierInfo* to CallDescription

Exactly what it says on the tin! I decided not to merge this with the patch that
changes all these to a CallDescri

[analyzer][MallocChecker][NFC] Change the use of IdentifierInfo* to CallDescription

Exactly what it says on the tin! I decided not to merge this with the patch that
changes all these to a CallDescriptionMap object, so the patch is that much more
trivial.

Differential Revision: https://reviews.llvm.org/D68163

show more ...


# 9fd7ce7f 26-Sep-2019 Kristóf Umann <dkszelethus@gmail.com>

[analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters

The following series of refactoring patches aim to fix the horrible mess that MallocChecker.cp

[analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters

The following series of refactoring patches aim to fix the horrible mess that MallocChecker.cpp is.

I genuinely hate this file. It goes completely against how most of the checkers
are implemented, its by far the biggest headache regarding checker dependencies,
checker options, or anything you can imagine. On top of all that, its just bad
code. Its seriously everything that you shouldn't do in C++, or any other
language really. Bad variable/class names, in/out parameters... Apologies, rant
over.

So: there are a variety of memory manipulating function this checker models. One
aspect of these functions is their AllocationFamily, which we use to distinguish
between allocation kinds, like using free() on an object allocated by operator
new. However, since we always know which function we're actually modeling, in
fact we know it compile time, there is no need to use tricks to retrieve this
information out of thin air n+1 function calls down the line. This patch changes
many methods of MallocChecker to take a non-optional AllocationFamily template
parameter (which also makes stack dumps a bit nicer!), and removes some no
longer needed auxiliary functions.

Differential Revision: https://reviews.llvm.org/D68162

show more ...


# 601687bf 30-Jan-2020 Charusso <dabis.csaba98@gmail.com>

[analyzer] DynamicSize: Remove 'getExtent()' from regions

Summary:
This patch introduces a placeholder for representing the dynamic size of
regions. It also moves the `getExtent()` method of `SubReg

[analyzer] DynamicSize: Remove 'getExtent()' from regions

Summary:
This patch introduces a placeholder for representing the dynamic size of
regions. It also moves the `getExtent()` method of `SubRegions` to the
`MemRegionManager` as `getStaticSize()`.

Reviewed By: NoQ

Differential Revision: https://reviews.llvm.org/D69540

show more ...


# adcd0268 28-Jan-2020 Benjamin Kramer <benny.kra@googlemail.com>

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...


# bce1cce6 18-Dec-2019 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] Teach MismatchedDealloc about initWithBytesNoCopy with deallocator.

MallocChecker warns when memory is passed into -[NSData initWithBytesNoCopy]
but isn't allocated by malloc(), because i

[analyzer] Teach MismatchedDealloc about initWithBytesNoCopy with deallocator.

MallocChecker warns when memory is passed into -[NSData initWithBytesNoCopy]
but isn't allocated by malloc(), because it will be deallocated by free().
However, initWithBytesNoCopy has an overload that takes an arbitrary block
for deallocating the object. If such overload is used, it is no longer
necessary to make sure that the memory is allocated by malloc().

show more ...


# 2f960472 03-Dec-2019 Tyker <tyker1@outlook.com>

[NFCI] update formating for misleading indentation warning

Reviewers: xbolva00

Reviewed By: xbolva00

Differential Revision: https://reviews.llvm.org/D70861


# 1b38002c 22-Sep-2019 Benjamin Kramer <benny.kra@googlemail.com>

Move classes into anonymous namespaces. NFC.

llvm-svn: 372495


# c90fda6a 21-Sep-2019 Kristof Umann <kristof.umann@ericsson.com>

Attempt to fix a windows buildbot failure

llvm-svn: 372462


# 96be6f48 20-Sep-2019 Kristof Umann <kristof.umann@ericsson.com>

Fix a documentation error

llvm-svn: 372419


# 951cd32f 20-Sep-2019 Kristof Umann <kristof.umann@ericsson.com>

Reland '[analyzer][MallocChecker][NFC] Document and reorganize some functions'

Differential Revision: https://reviews.llvm.org/D54823

llvm-svn: 372414


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5
# 72649423 12-Sep-2019 Kristof Umann <kristof.umann@ericsson.com>

[analyzer][NFC] Fix inconsistent references to checkers as "checks"

Traditionally, clang-tidy uses the term check, and the analyzer uses checker,
but in the very early years, this wasn't the case, a

[analyzer][NFC] Fix inconsistent references to checkers as "checks"

Traditionally, clang-tidy uses the term check, and the analyzer uses checker,
but in the very early years, this wasn't the case, and code originating from the
early 2010's still incorrectly refer to checkers as checks.

This patch attempts to hunt down most of these, aiming to refer to checkers as
checkers, but preserve references to callback functions (like checkPreCall) as
checks.

Differential Revision: https://reviews.llvm.org/D67140

llvm-svn: 371760

show more ...


# 6b85f8e9 11-Sep-2019 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.

These static functions deal with ExplodedNodes which is something we don't want
the PathDiagnostic interface to know anyth

[analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.

These static functions deal with ExplodedNodes which is something we don't want
the PathDiagnostic interface to know anything about, as it's planned to be
moved out of libStaticAnalyzerCore.

Differential Revision: https://reviews.llvm.org/D67382

llvm-svn: 371659

show more ...


# 8535b8ec 11-Sep-2019 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] NFC: Re-implement stack hints as a side map in BugReport.

That's one of the few random entities in the PathDiagnostic interface that
are specific to the Static Analyzer. By moving them ou

[analyzer] NFC: Re-implement stack hints as a side map in BugReport.

That's one of the few random entities in the PathDiagnostic interface that
are specific to the Static Analyzer. By moving them out we could let
everybody use path diagnostics without linking against Static Analyzer.

Differential Revision: https://reviews.llvm.org/D67381

llvm-svn: 371658

show more ...


Revision tags: llvmorg-9.0.0-rc4
# 2f169e7c 09-Sep-2019 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.

Checkers are now required to specify whether they're creating a
path-sensitive report or a path-insensitive report by cons

[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.

Checkers are now required to specify whether they're creating a
path-sensitive report or a path-insensitive report by constructing an
object of the respective type.

This makes BugReporter more independent from the rest of the Static Analyzer
because all Analyzer-specific code is now in sub-classes.

Differential Revision: https://reviews.llvm.org/D66572

llvm-svn: 371450

show more ...


Revision tags: llvmorg-9.0.0-rc3
# 630f7daf 28-Aug-2019 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] Fix analyzer warnings on analyzer.

Write tests for the actual crash that was found. Write comments and refactor
code around 17 style bugs and suppress 3 false positives.

Differential Rev

[analyzer] Fix analyzer warnings on analyzer.

Write tests for the actual crash that was found. Write comments and refactor
code around 17 style bugs and suppress 3 false positives.

Differential Revision: https://reviews.llvm.org/D66847

llvm-svn: 370246

show more ...


12345678910>>...16