about summary refs log tree commit diff homepage
path: root/lib/Core/Memory.h
AgeCommit message (Collapse)Author
2017-04-09Removed unused variable 'fake_object' in MemoryObjectAndrea Mattavelli
2015-12-18Fix memory leaks of ``Array`` objects detected by ASan.Dan Liew
Some of these leaks were introduced by the factory constructor for Array objects (f049ff3bc04daead8c3bb9f06e89e71e2054c82a) but a few others have been around for far longer. This leak was fixed by introducing a ``ArrayCache`` object which has two purposes * Retains ownership of all created ``Array`` objects and destroys them when the ``ArrayCache`` destructor is called. * Mimic the caching behaviour for symbolic arrays that was introduced by f049ff3bc04daead8c3bb9f06e89e71e2054c82a where arrays with the same name and size get "uniqued". The Executor now maintains a ``arrayCache`` member that it uses and passes by pointer to objects that need to construct ``Array`` objects (i.e. ``ObjectState``). This way when the Executor is destroyed all the ``Array`` objects get freed which seems like the right time to do this. For Kleaver the ``ParserImpl`` has a ``TheArrayCache`` member that is used for building ``Array`` objects. This means that the Parser must live as long as the built expressions will be used otherwise we will have a use after free. I'm not sure this is the right design choice. It might be better to transfer ownership of the ``Array`` objects to the root ``Decl`` returned by the parser.
2012-01-18Nice patch by Gang Hu, Heming Cui and Junfeng Yang fixing a memoryCristian Cadar
leak in KLEE. From Gang Hu: "The memory leak is caused by two reasons. First, the MemoryObject objects are not freed, until the MemoryManager is destroyed. Second, when KLEE allocates a non-fixed MemoryObject object, KLEE also allocates a block of memory which is the same as the object's size. This block of memory is never freed. So, this patch generally does reference counting on the MemoryObject objects, and frees them as soon as the reference count drops to zero." Many thanks to Paul Marinescu as well, who tested this patch thoroughly on the Coreutils benchmarks. On 1h runs, the memory consumption typically goes down by 1-5%, but some applications which see more significant gains. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@148402 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-02Fix some const cast warnings.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@102867 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-28Move Machine constants into Context object, initialized based on the targetDaniel Dunbar
data. - This is the first step towards having KLEE be fully target independent, its not particularly beautiful but its expedient. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@77306 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26Simplify read/write code.Daniel Dunbar
- Get rid of unnecessary special cases. - Support read/write of large integers. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@74286 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-14More ConstantExpr cleanup.Daniel Dunbar
- Change Executor::evalConstant to return ConstantExpr. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73337 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-13Switch to using constant arrays for non-symbolic objects.Daniel Dunbar
- Currently uses a dumb implementation which keeps the old flushing architecture, but converts to a constant array when the first ReadExpr is created. - Temporary --use-constant-arrays switch can be used to disable for testing. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73313 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-13Create new ObjectState constructor for explicitly creating symbolic objects.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73308 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-10Move Array construction out of MemoryObject into ObjectState.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73162 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-09Remove Array::object.Daniel Dunbar
- The sole remaining client was IVC, which is currently disabled for other correctness issues. I patched it to compile and left a FIXME that we will have to resolve this before we can reenable IVC. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73129 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-09Remove Array::id.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73128 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-09Add Array::name field, initialized but not used for anything yet.Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73125 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-02Use ConstantExpr::alloc instead of ref<Expr> directlyDaniel Dunbar
- The "constant optimization" embedded inside ref<Expr> is going away. - No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@72730 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-21Initial KLEE checkin.Daniel Dunbar
- Lots more tweaks, documentation, and web page content is needed, but this should compile & work on OS X & Linux. git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@72205 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit-pink 1.4.1 (git 2.36.1) at 2025-02-20 06:45:56 +0000