Synchronized KLEE with klee/klee and Fixed Memory Errors #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MemorySanitzer and ThreadSanitizer environment variables when running lit tests. This makes it easy suppress errors in sanitized versions of KLEE
which is required to suppress all the leaks I'm currently seeing in KLEE when running ``make unittests`` and ``make check``. Ideally there should be no leaks but we aren't there yet. Hopefully at some point we won't need to suppress any leaks and then we can have a TravisCI build that builds with ASan. The leak of the expression objects when running the executor is worrying and I will investigate this next.
The overloaded assignment operator previously only deleted the head ``UpdateNode`` if the ``UpdateList`` had exclusive ownership which left the remaining list of ``UpdateNode``s dangling if those nodes had ``refCount`` of 1. To fix this the logic that was previously in the ``UpdateList`` destructor for deleting nodes that were exclusively referenced by the UpdateList has been moved into ``UpdateList::tryFreeNodes()`` so that it can be called from ``UpdateList::operator=()``. It looks like this bug has been in KLEE since the beginning.
Fix a memory leak in ``UpdateList`` detected by AddressSanitizer.
… Support directory
Use "-debug-dump-stp-queries" argument for KLEE/Kleaver to print out each STP query sent to the STP Solver. Queries have the format which `stp` frontend can understand.
helper functions.
Some of these leaks were introduced by the factory constructor for Array objects (f049ff3) 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 f049ff3 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.
Try to fix leaking Array objects detected by ASan.
so that it is possible to ``#include "klee/util/ArrayExprHash.h"``
``include/klee/util/ArrayCache.h``.
the ``ParserImpl`` it wouldn't free allocated ``Identifier``s
introduced in LLVM 2.7. Previously KLEE would emit the following error message when ``IntrinsicLowering::LowerIntrinsicCall()`` was called on the intrinsic ``` LLVM ERROR: Code generator does not support intrinsic function 'llvm.objectsize.i64.p0i8'! ``` The ``IntrinsicCleaner`` pass now lowers this intrinsic to a constant integer depending on the second argument to the intrinsic. This corresponds to the case where the size of the object pointed to by the first argument is unknown. An alternative design would be to handle this intrinsic in the Executor where is actually possible to know the size of objects during execution. However that would be much more complicated because if the pointer is symbolic we would have to fork for every object that could be pointed to. The implementation is similar to #260 but we handle the second argument to the intrinsic correctly and also have a simple test case. Unfortunately we have to have a different version of the test case for LLVM 2.9 because the expected suffix for the intrinsic is different in LLVM 2.9.
Fix duplication of klee::ArrayHashFn
Fix a leak detected by ASan in the KQuery parser where on destruction of
Implement support for lowering the ``llvm.objectsize`` intrinsic
``IndependentSolver::computeInitialValues()`` was called where at least one of the constraint sets computed by ``getAllIndependentConstraintsSets()`` is either unsatisfiable or the solver failed. To make things (a little) clearer I've made it so that no ``std::list<>*`` is passed to``getAllIndependentConstraintsSets()``. Instead ``getAllIndependentConstraintsSets()`` now returns a ``std::list<>*`` that the caller is responsible for cleaning up. The behaviour previously was really confusing because it was unclear if the caller or callee was responsible for the clean up. This fixes #322
… with Clang 3.4.2
Removed Language: Cpp Entry from .clang-format
Fix independence solver leak
…onState's addConstraint method
…xecutionState constructors
…to already-deallocated memory
domainexpert
changed the title
domainexpert
added a commit
that referenced
this pull request
Jan 9, 2016
Synchronized KLEE with klee/klee and Fixed Memory Errors
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The comment was updated to clarify issues #10 and #11.