This matches the command-line API described in the paper, and lets users
invoke the Manticore backend without relying on the fact that it is the
default (which might change).
Clarify the readme:
* incorporated the paper reference into the first paragraph so it gets excerpted together
* removed a lot of extraneous guidance from the building and installing sections
* added a new contributing section that notes the "good first issue" label, bounties, and our Slack
* noted the the best usage guidance is available in the examples and readme for now
We only want to save a `.crash` file if the input would cause a crash
when executing using the native harness. The old impl treated any state
termination as a crash. Now we add a predicate which checks the `reason`
and decides if the termination represents a crash in the program being
analyzed.
For now, we only flag `InvalidMemoryAccess` exceptions as crashes, as
identified by the `message` property on a `TerminateState` exception.
We don't just want to exit here, but `longjmp()` back to the conditional
via a call to `DeepState_Fail()`. In doing so, we end up in the common
`DeepState_CatchFail()` branch, which exits with the same nonzero error
code, but also saves the test case if appropriate.
When an assertion fails in the C++ API, it ultimately invokes a
`Fatal`-level `DeepState_Log()`. This calls `DeepState_Fail()`, which
longjmps. If we don't clear the log buffer here, it won't get cleared by
the usual logic which does so. This causes hanging, unflushed log
messages to persist between tests.
This relationship should eventually be inverted and decoupled.
Not using a more specific binary causes build failures on systems where
the default Python is 3. The existing backends, angr and Manticore, both
require Python 2.7, so we can look at supporting Python 3 when they do.
Alex Groce
Joe Ranweiler
Peter Goodman
Dan Guido