Giter Site home page Giter Site logo

viperproject / silicon Goto Github PK

View Code? Open in Web Editor NEW
78.0 6.0 31.0 38.54 MB

Symbolic-execution-based verifier for the Viper intermediate verification language.

License: Mozilla Public License 2.0

Scala 95.21% Batchfile 0.19% Shell 0.51% SMT 0.89% AutoHotkey 0.05% Python 0.38% Boogie 2.77%
viper verification symbolic-execution

silicon's Introduction

Silicon: A Viper Verifier Based on Symbolic Execution

Silicon logo

Silicon is a state-of-the-art, automated verifier based on symbolic execution, and the default verifier of the Viper verification infrastructure. Silicon's input language is the Viper intermediate verification language: a language in the spirit of Microsoft's Boogie, but with a higher level of abstraction and a built-in notation of permissions, which makes Viper well-suited for encoding and verifying properties of sequential and concurrent programs with shared mutable state. Loads of details can (but don't need to) be found in the PhD thesis of Malte Schwerhoff.

As an example, consider the following simple C++ program, which runs two threads in parallel that increment a shared memory location and that uses a lock to avoid race conditions:

#include <thread>
#include <mutex>
#include <assert.h>

struct Cell {
  int val;
};

void inc(Cell* c, std::mutex* guard) {
  guard->lock();
  
  int t = c->val;
  std::this_thread::sleep_for(std::chrono::seconds(1));
  c->val = t + 1;
  
  guard->unlock();
}

int main() {
  Cell* c = new Cell{0};
  std::mutex* guard = new std::mutex();
  
  std::thread t1 = std::thread(inc, c, guard);
  std::thread t2 = std::thread(inc, c, guard);

  t1.join();
  t2.join();
  
  guard->~mutex();
  assert(c->val == 2);

  return 0;
}

Such a program can be encoded in Viper, e.g. using an Owicki-Gries approach as shown below, and Silicon can be used to automatically verify that the shared memory location is indeed modified in an orderly manner.

field val: Int
field t1: Int
field t2: Int

// Monitor/lock invariant associated with the shared cell
// Macro'ed for easy reuse
define guard_INV(c)
  acc(c.val) && acc(c.t1, 1/2) && acc(c.t2, 1/2) &&
  c.val == c.t1 + c.t2

// Precondition of inc
define inc_PRE(c, tid)
  (tid == 0 || tid == 1) &&
  (tid == 0 ? acc(c.t1, 1/2) : acc(c.t2, 1/2))
  
// Postcondition of inc
define inc_POST(c, tid, oldv)
  tid == 0 ? (acc(c.t1, 1/2) && c.t1 == oldv + 1)
            : (acc(c.t2, 1/2) && c.t2 == oldv + 1)

method inc(c: Ref, tid: Int)
  requires inc_PRE(c, tid)
  ensures  inc_POST(c, tid, tid == 0 ? old(c.t1) : old(c.t2))
{
  inhale guard_INV(c) // models guard.lock()
  
  c.val := c.val + 1
  
  if (tid == 0) { c.t1 := c.t1 + 1 }
  else { c.t2 := c.t2 + 1 }
  
  exhale guard_INV(c) // models guard.unlock()
}

method main() {
  var c: Ref
  c := new(val, t1, t2) // allocate real and ghost memory
  c.val := 0
  c.t1 := 0
  c.t2 := 0
  
  exhale guard_INV(c) // share the cell, i.e. create the guarding mutex
  
  label pre_fork
  exhale inc_PRE(c, 0) // fork thread 1
  exhale inc_PRE(c, 1) // fork thread 2
  
  inhale inc_POST(c, 0, old[pre_fork](c.t1)) // join thread 1
  inhale inc_POST(c, 1, old[pre_fork](c.t2)) // join thread 2
  
  inhale guard_INV(c) // unshare the cell, i.e. destroy the mutex
  
  assert c.val == 2;
}

Getting Started

  • Download the Viper IDE (based on Microsoft Visual Studio Code).

  • Experiment with Viper using the Viper online web interface.

Build Instructions

See the documentation wiki for instructions on how to try out or install the Viper tools.

  • You need recent installations of
    1. the sbt build tool
    2. the Z3 SMT solver
    3. (optional) the cvc5 SMT solver
  • Clone this repository recursively by running:
    git clone --recursive https://github.com/viperproject/silicon

And then, from the cloned directory, with the Z3_EXE environment variable set appropriately;

  • Compile and run with:
    sbt "run [options] <path to Viper file>"
    Or run all tests via sbt test
  • Alternatively, for a faster startup without compilation each time, build a .jar file:
    sbt assembly
    And then run with:
    java -jar ./target/scala-*/silicon.jar [options] <path to Viper file>

We recommend IDEA IntelliJ for Scala development, but any IDE that supports sbt will do

silicon's People

Contributors

aimenel avatar alexanderjsummers avatar arquintl avatar aterga avatar aurecchia avatar aurel300 avatar brotobia avatar cedihegi avatar dspil avatar fabianboesiger avatar fabiopakk avatar fpoli avatar fstreun avatar jcp19 avatar jonasalaif avatar lfwa avatar manud99 avatar marcoeilers avatar maurobringolf avatar mlimbeck avatar mousam05 avatar mschwerhoff avatar simon-hostettler avatar stefanheule avatar tdardinier avatar tschoesi avatar ueliomuelio avatar vakaras avatar wytseoortwijn avatar zgrannan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

silicon's Issues

Postconditions seems to be ignored

Created by bitbucket user stefanheule on 2012-12-30 00:16
Last updated on 2013-04-26 18:44

It appears that Silicon ignores postconditions, as adding the postcondition as an assertion at the end of a method can change the behavior.

Examples include (according to benchmark.xlsx by Christian) benchmarks/Misc/cell_raw.chalice, and others.


Attachments:

Reporting multiple errors/continue verification assuming that a failed assertion holds

Created by @mschwerhoff on 2013-07-23 08:36
Last updated on 2016-04-04 12:00

Silicon currently stops the verification of the current member when the first error is found. This is different from Carbon (and Chalice) , which continues the verification and thus might report more errors.

It should be possible for Silicon to continue the verification if the failing assertion is a boolean one. The situation is different for non-boolean assertions, e.g., insufficient permissions or missing heap chunks, because it is not clear how one would modify the heap in a way that does not give rise to spurious subsequent errors.

Epsilon permissions not supported

Created by @alexanderjsummers on 2012-12-11 18:31
Last updated on 2015-01-28 10:57

Epsilon permissions are currently not handled by Silicon (and cause an informative exception to be thrown). It would be nice if either these could be handled, or it could be demonstrated that we can do without epsilons, using a stronger encoding of abstract read permissions as Syxc now supports (I believe).

This affects e.g., FictionallyDisjointCells.chalice (although that example also fails translation due to another issue). Other examples from the Chalice test suite include basic.chalice, predicates.chalice, predicate_error1.chalice etc..


Attachments:

Permission incompletenesses

Created by @mschwerhoff on 2013-04-15 07:14
Last updated on 2017-09-23 13:41

The separation of the symbolic state into a heap and path conditions entails permission-related incompletenesses of various kinds and degrees. Silicon's current implementation several strategies to overcome them, for example

  • heap compression if "assert true" is executed
  • heap compression after new chunks are produced
  • definitely-not-aliases information is computed from the heap when heaps are compressed
  • chunks are first looked-up by a syntactic match, if this fails, by a semantic match (asking Z3)

However, several incompletenesses still exist, as illustrated by this test file (tip version).

My suggestion is to define an interface for heap lookups and to implement different heap lookup strategies that will (or can) be used a certain order. Questions to keep in mind are:

  • Can the heap stay as it is, that is, without much business logic?
  • Can chunks still be created manually or should the heap provide methods such as gainAccess, losePermissions or withChunk?
  • Can we hold on to the invariant that if a chunk exists, then its permissions are definitely positive?

Attachments:

Incompleteness Related to Short-Circuit Evaluation and Zero Divisor

Created by bitbucket user evolutics on 2013-08-07 21:10
Last updated on 2013-08-10 19:58

Verifying the program

method checkGcd(left: Int, right: Int)
  requires left >= 0 && right >= 0
  ensures right == 0 || left % right >= 0
{ }

in Silicon gives me the failure

[not.wellformed:division.by.zero] Contract might not be well-formed. Divisor right might be zero.

However, with short-circuit evaluation, right cannot be zero in the subexpression left % right >= 0.

Wildcard permission causes Match Error

Created by bitbucket user bbrodowsky on 2013-04-17 11:23
Last updated on 2013-04-25 15:44

If any wild card permission appears inside a program, silicon crashes. ReadPermissions.scala in scala2sil contains examples, the translated sil program is attached.


Attachments:

Assertion failure in internal map data structure

Created by @alexanderjsummers on 2012-12-11 18:19
Last updated on 2013-04-18 14:32

Translating the Chalice test case cell.chalice causes Silicon to throw

Exception in thread "main" java.lang.AssertionError: assertion failed: Looking up result in Map(this -> c_12@71) failed.
at scala.Predef$.assert(Predef.scala:103)
at ch.ethz.inf.pm.silicon.state.MapBackedStore.get(State.scala:42)
at ch.ethz.inf.pm.silicon.state.MapBackedStore.apply(State.scala:31)
at ch.ethz.inf.pm.silicon.DefaultEvaluator$class.evalt2(Evaluator.scala:789)

The translation includes a warning that "free" nodes are not supported. However, commenting out the "free this;" statement in the example (which is only relevant for the leak-checking option in Chalice) does not change the behaviour, so this is likely unrelated.


Attachments:

New objects and non-aliasing information

Created by @mschwerhoff on 2013-05-24 15:38
Last updated on 2019-03-02 22:27

When an object is created as v := new(), Silicon should be able to assert that every object that was reachable before calling new must be different from v. Silicon is currently only able to prove this non-equality between v and objects that were directly accessible, i.e., that were not "hidden" in a predicate. This is, because Silicon collects all reference-typed constants that are directly found in the store or in heap chunks.

In order to make Silicon (more) complete one could introduce "timestamps" that order references according to when they came into scope. The timestamp of a predicate would then be passed on to references that are unfolded from it. Another approach would be to adapt the approach of Spec#.

An example can be found in the test case Sil:basic/new.sil.

Permissions after new

Created by bitbucket user bbrodowsky on 2013-04-17 20:56
Last updated on 2013-04-23 11:53

After new(), full permissions on all fields should be available, but no permissions are actually available.

Usage of Axiom about Case Distinction for Structural Induction

Created by bitbucket user evolutics on 2013-07-28 16:42
Last updated on 2017-02-28 16:30

Given a domain Natural with a maximum function maximum(Natural, Natural): Natural, I am trying to verify the property

forall a: Natural, b: Natural :: maximum(a, b) == maximum(b, a)

by structural induction on Natural. By the way, this is property number 23 of the IsaPlanner examples.

The two functions zero(): Natural and successor(n: Natural): Natural construct Natural, thereby serving as a base for the induction principle on Natural. The attached file is the SIL program with more details.

The property is verified by Silicon for the case of zero. However, the proof obligation involving successor

forall a: Natural ::
  (forall n: Natural :: maximum(a, n) == maximum(n, a)) ==>
    forall b: Natural :: maximum(successor(a), b) == maximum(b, successor(a))

fails to verify. One of the required axioms is

axiom zeroOrSuccessor {
  forall n: Natural :: n == zero() || exists p: Natural :: n == successor(p)
}

but it does not seem to help for a case distinction on whether b == zero() or not in the proof obligation. If it is manually translated to

forall a: Natural ::
  (forall n: Natural :: maximum(a, n) == maximum(n, a)) ==>
    forall b: Natural ::
      (b == zero() || exists p: Natural :: b == successor(p)) ==>
        maximum(successor(a), b) == maximum(b, successor(a))

Silicon can verify it. It would be great if Silicon could do this automatically.


Attachments:

Match error on IfThenElseTerm

Created by @alexanderjsummers on 2012-12-11 18:43
Last updated on 2013-04-18 14:34

Silicon throws a match error when encountering IfThenElseTerm nodes; e.g.,

Exception in thread "main" scala.MatchError: IfThenElseTerm(!this.Node::next==null,1+this.Node::next.Node::size(),1) (of class semper.sil.ast.expressions.terms.PIfThenElseTermC)
at ch.ethz.inf.pm.silicon.DefaultEvaluator$class.evalt2(Evaluator.scala:783)
at ch.ethz.inf.pm.silicon.DefaultMemberVerifier.evalt2(Verifier.scala:194)
...

for the Chalice test case linkedlist.chalice (attached)

Also affects test case AVLTree.nokeys.chalice, ll-lastnode.chalice and probably others


Attachments:

Proof oblication perm > 0 for acc(f, perm)

Created by bitbucket user bbrodowsky on 2013-04-17 11:35
Last updated on 2013-04-23 13:45

If acc(f, perm) appears in a precondition, it should automatically add the proof obligation perm > 0, but this doesn't happen. No examples are included since scala2sil generates perm > 0 as a workaround.

Unique functions not implemented

Created by bitbucket user bbrodowsky on 2013-04-26 20:56
Last updated on 2013-05-01 17:00

Silicon seems to ignore the "unique" flag of domain functions. They are very important for the type system, however. In particular, some axioms contain t != Nothing and they are useless now.

Proving linked list properties fails

Created by @mschwerhoff on 2013-06-05 15:42
Last updated on 2013-08-06 12:41

Benjamin reported an incompleteness of Syxc, namely, that it is not able to prove that xs.next.next == null if xs is a list of length two. I translated the example to Sil (see test file Sil:all/issues/silicon/0033.sil) and Silicon seems to suffer from the same incompleteness.

Constant in permission

Created by bitbucket user bbrodowsky on 2013-04-18 21:40
Last updated on 2013-04-22 08:52

Using constants (i.e. nullary domain functions) inside permission results in an error.

[info] - translation/Permissions.scala [Silicon] *** FAILED ***
[info] java.lang.RuntimeException: [consumeExactRead] Found unexpected case (Perm) globalRdPerm()
[info] at scala.sys.package$.error(package.scala:27)
[info] at semper.silicon.DefaultConsumer$class.consumeExactRead(Consumer.scala:227)
[info] at semper.silicon.DefaultConsumer$class.semper$silicon$DefaultConsumer$$consumePermissions(Consumer.scala:211)
[info] at semper.silicon.DefaultConsumer$$anonfun$4$$anonfun$apply$6.apply(Consumer.scala:138)
[info] at semper.silicon.DefaultConsumer$$anonfun$4$$anonfun$apply$6.apply(Consumer.scala:136)
[info] at semper.silicon.DefaultEvaluator$$anonfun$evalp$1.apply(Evaluator.scala:72)
[info] at semper.silicon.DefaultEvaluator$$anonfun$evalp$1.apply(Evaluator.scala:70)
[info] at semper.silicon.DefaultEvaluator$$anonfun$eval$1.apply(Evaluator.scala:96)
[info] at semper.silicon.DefaultEvaluator$$anonfun$eval$1.apply(Evaluator.scala:95)
[info] at semper.silicon.DefaultEvaluator$$anonfun$eval2$1.apply(Evaluator.scala:107)


Attachments:

Interference between local evaluations and non-local branching

Created by @mschwerhoff on 2013-07-30 15:34
Last updated on 2013-08-06 12:15

Silicon inherited a problem from Syxc that is due to non-local branchings happening during local evaluations. I never really managed to pin down and solve the problem, although I tried it several times and always invested a couple of days. Here is the gist of the problem described using a ternary if-then-else, but it is similar for implications and conjunctions.

Locally evaluating, for example, a conjunct b ? e1 && e2 together with the continuation Q, proceeds by

  1. evaluating b into tb

  2. locally evaluating e1 by

    1. assuming tb

    2. evaluating e1, but instead of continuing with Q

    3. recording the result (called actual result) and the resulting path conditions (called auxiliary terms) of the evaluation of e1 in local variables tAR1 and tAux1, respectively

    4. terminating the local evaluation of e1 by returning Success which makes the symbolic execution backtrack until the point where the evaluation of e1 started

  3. locally evaluating e2 analogous to e1, but assuming !tb and storing the results in different local variables

  4. continuing the original execution Q under the auxiliary assumptions tb ? tAux1 : tAux2 and with the actual evaluation result tb ? tAR1 : tAR2

This turned out to be wrong when the evaluation of e1 or e2 branches non-locally, for example, because they (transitively) contain a requires bb ==> acc(this.f). In this case, step 2.3 (and 2.4) are done twice, once in the bb case and once in the !bb case. The second actual result and auxiliary terms overwrote the previous ones, and the original execution thus finally continued with a "partial" actual evaluation result and under "partial" auxiliary assumptions.

This can result in incompletenesses (see test file Sil:all/issues/silicon/0039a.sil) as well as unsoundnesses (see test file Sil:all/issues/silicon/0039b.sil).

Name clashes in Z3

Created by @mschwerhoff on 2013-04-19 15:15
Last updated on 2014-06-04 05:45

If the same instance of Silicon is used to verify multiple programs it can come to name clashes in Z3. Z3 is apparently not correctly reset. For now, Bernhard works around this problem by making sure that each class in the whole test suite has a unique name, but that is of course no proper solution.

Missing Verification Failure about Null Reference

Created by bitbucket user evolutics on 2013-08-07 08:04
Last updated on 2013-08-10 19:07

The following program is successfully verified by Silicon:

var next: Ref

predicate valid(list: Ref)
{ acc(list.next, write) && (list.next != null ==>
    acc(list.next.valid(), write)) }

function size(list: Ref): Int
  requires acc(list.valid(), epsilon)
  ensures result >= 1
{ unfolding acc(list.valid(), epsilon) in
    list.next == null ? 1 : 1 + size(list.next) }

If I am not mistaken about the semantics of SIL, the reference list of the function size could be null (which is different from predicates, which always require the first reference to be non-null). Thus, the program should only verify with a precondition like

requires list != null && acc(list.valid(), epsilon)

Error at location 0.0

Created by bitbucket user stefanheule on 2012-12-28 22:16
Last updated on 2015-02-05 19:09

Silicon reports an error for location 0.0 when verifying the test benchmark/ForkJoin/predicates_fork_join.chalice, instead of line 177. This might also be a problem with sil.ast, or chalice2sil. At the moment, the test is ignored.


Attachments:

Configure where to look for Z3

Created by @mschwerhoff on 2013-02-01 14:32
Last updated on 2013-03-25 16:36

Instead of solely relying on Z3 being in the system's path, Silicon should also take an environment variable such as Z3_PATH into account.

Non-aliasing assumptions from unfolding predicates

Created by @mschwerhoff on 2013-07-31 08:48
Last updated on 2019-11-16 14:58

Additional non-aliasing assumptions could be generated when unfolding permissions, as illustrated by the following program:

field next: Ref

predicate valid(this: Ref) {
  acc(this.next, wildcard) &&
  (((this.next) != (null)) ==> acc(valid(this.next), wildcard))
}

method testNestingUnfold(this: Ref)
  requires acc(valid(this), wildcard)
{
  unfold acc(valid(this), wildcard)
  assert ((this) != (this.next))

  if (((this.next) != (null))) {
    unfold acc(valid(this.next), wildcard)
    assert ((this.next) != (this.next.next))
    assert ((this) != (this.next.next))
  }
}

This is currently not done in Silicon.

Silicon fails to terminate (in reasonable time) on predicate/functions example

Created by @alexanderjsummers on 2012-12-13 17:32
Last updated on 2015-11-24 12:30

In the attached case (a simplified version of lseg.chalice from the Chalice test suite), Silicon doesn't terminate. Z3 appears to be (sporadically) invoked, so it's not just a loop in the Scala code directly, I guess.

It seems likely that the issue is to do with using a function inside a predicate definition - possibly that causes the loop. On Syxc, I get a stack overflow error. On Chalice the example verifies fairly fast.


Attachments:

Variable can be null after new()

Created by bitbucket user bbrodowsky on 2013-04-17 11:15
Last updated on 2013-04-23 12:00

After a := new(), a should be guaranteed to be non-null. However, in Silicon, this is not the case. Fields.scala in scala2sil shows this problem (translated sil file attached)


Attachments:

Completness of Functions/Predicates

Created by bitbucket user stefanheule on 2012-12-16 14:49
Last updated on 2013-04-22 09:12

Silicon seems to be unable to prove properties about function when predicates are involved. The attached files contains two IgnoreError annotations where chalice2sil (with Silicon) fails to show an assertion that holds.

The attached file has been taken from translation/Predicates/test1.chalice.


Attachments:

assert(false) after terminating while loop

Created by bitbucket user bbrodowsky on 2013-04-30 23:15
Last updated on 2013-05-01 21:45

If a while loop gets executed at least once (i.e. the condition is not false when entered), Silicon does not complain if assert(false) appears after the loop. An example is given in Issue027.scala.

Unrolling functions depending on manually (un)folded predicates (ECOOP'13)

Created by @mschwerhoff on 2013-07-31 12:59
Last updated on 2015-12-15 13:12

In ECOOP'13, Heule et. al describe how Chalice generates additional triggers for functions depending on predicates that have been (un)folded explicitly by the user. Silicon currently doesn't do something comparable, and thus fails two prove assertions that require a deeper function unrolling. For example, if a linked list is folded three levels deep and it should be asserted that its length is now three.

For a general support of this scheme it might be necessary (or beneficial in terms of performance) to axiomatise functions instead of evaluating them on-the-fly.

Finding predicates with arguments in the heap

Created by @mschwerhoff on 2013-07-25 10:23
Last updated on 2017-09-23 13:47

As illustrated by the test file Sil:all/predicates/arguments.sil, Silicon isn't able to verify snippets such as

inhale acc(this.valid(b), write)
inhale acc(this.valid(!b), write)
exhale acc(this.valid(true), write)

It is obvious that the prover needs to be invoked when looking for a matching heap chunk. It is not obvious, however, how to proceed. Since b and !b are both may- but not must-matches, one could i) just pick the first may-match and ignore other possibilities or ii) branch and try all possibilities.

Unify data recording and handling

Created by @mschwerhoff on 2013-03-18 14:50
Last updated on 2016-06-23 13:23

Silicon currently has various places where data is recorded

  • brandingData object generated by sbt-brand
  • Bookkeeper
  • Context
  • timestamps that are formatted in different places

Some of the data is constant (sbt-brand), some is valid for the whole lifetime of a Silicon instance, some is only valid for a single run.

Multi-phase exhaling of permissions

Created by @mschwerhoff on 2013-05-25 12:20
Last updated on 2016-04-15 11:59

The multi-phase exhaling as described in the permission paper by Heule, Summers et al. is not yet implemented in Silicon. This results, for example, in the unsoundness exhibited by the unexpectedly sucessful test case t2b in Sil:all/basic/fresh.sil.

Failing post-conditions with function calls report incorrect source locations

Created by @alexanderjsummers on 2012-12-13 18:56
Last updated on 2013-12-23 19:18

When a postcondition that mentions a function call fails to verify (possibly because the pre-condition of the function is not available), the source location reported is that of the function definition, and not the failing postcondition.

For example, the attached Chalice test case cell-defaults.chalice (which contains many failures, because it exercises the automatic features of Chalice) produces numerous identical error messages, but it should report errors in each post-condition.

This may also be an error in translation, in which case the issue should be moved to Chalice2SIL. But I suppose that the error reporting is using the wrong node to lookup source information.


Attachments:

Read permissions in function postconditions

Created by bitbucket user bbrodowsky on 2013-04-26 20:54
Last updated on 2013-05-01 21:52

In some cases (but not always) the verifier is not happy about fields used in the postconditions of functions even though the permissions are available. Issue024.scala contains an example.

Functions with old expressions in postcondition cannot be proven

Created by bitbucket user stefanheule on 2012-12-15 10:01
Last updated on 2013-04-18 14:41

The method increase of translation/Examples/predicatesCompareOld.chalice has a postcondition old(getCount()) <= getCount() which fails to verify. The translation to SIL seems correct and yields:

:::java
implementation Indentation::increase(this : ref,amount#32 : Integer,k_a : Permission,$currentThread_b : ref) : ()
    requires !(this=null)
    requires 0<k_a && 1000*k_a<write
    requires !($currentThread_b=null) && acc($currentThread_b.$Thread::heldMap,write) && acc($currentThread_b.$Thread::muMap,write)
    requires acc(this.Indentation::valid,write) && 0<=amount#32
    ensures acc($currentThread_b.$Thread::heldMap,write) && acc($currentThread_b.$Thread::muMap,write)
    ensures forall o_c : ref :: (Map[ref,Boolean].get(old($currentThread_b.$Thread::heldMap),o_c)=Map[ref,Boolean].get($currentThread_b.$Thread::heldMap,o_c))
    ensures forall o_d : ref :: (Map[ref,Boolean].get($currentThread_b.$Thread::heldMap,o_d) ==> Map[ref,Mu].get(old($currentThread_b.$Thread::muMap),o_d)=Map[ref,Mu].get($currentThread_b.$Thread::muMap,o_d))
    ensures acc(this.Indentation::valid,write)
    ensures old(this.Indentation::getCount())<=this.Indentation::getCount()
{

    entry:{
        unfold acc(this.Indentation::valid,write)
        this.Indentation::count := this.Indentation::count+amount#32
        fold this.Indentation::valid by write
    }
}

For now, the error is suppressed using IgnoreError.

Indefinite Verification with CAT

Created by bitbucket user evolutics on 2013-09-01 10:09
Last updated on 2014-09-01 14:22

The attached (not so minimal) SIL program is successfully verified by Silicon. However, if line 448 with the third manual CAT (cases axiom triggering) is removed, the verification does not terminate within half an hour on my (elderly) laptop.


Attachments:

Type Seq[DomainType[]] results in MatchError.

Created by bitbucket user bbrodowsky on 2013-05-29 17:26
Last updated on 2013-06-05 15:44

Match error at semper.silicon.state.DefaultSymbolConvert.toSort(SymbolConverter:30) for the Sequence Type of a domain type. Every test in scala2sil is a test case. (Hence I cannot check if my changes are broken)

Constraining and rewriting permission expressions

Created by @mschwerhoff on 2013-07-25 10:05
Last updated on 2019-08-28 09:29

As illustrated by test file Sil:all/permissions/abstract.sil, permission expressions such as

exhale acc(this.f, (1/2) * (n * rd + 1/2))
exhale acc(this.f, (1/2) - ((1/4) - n*rd))
exhale acc(this.f, (1/4) - ((-100)*rd))

may fail inside fresh(rd) {...} blocks although they shouldn't.

Rewriting them, for example, by multiplying them out or pulling in subtractions, would yield:

exhale acc(this.f, ((1/2) * n * rd) + (1/2))
exhale acc(this.f, (1/4) + n*rd))
exhale acc(this.f, (1/4) + 100*rd))

Silicon can already handle such exhales if they are split at + into multiple exhales, e.g., exhale acc(this.f, (1/2)) && exhale acc(this.f, (1/2) * n * rd). Once multi-phase inhaling (see #30) is implemented it should not longer be necessary to split them into different exhales.

Unexpected Output of Z3 Because of Unknown Function/Constant

Created by bitbucket user evolutics on 2013-07-27 18:15
Last updated on 2013-08-09 14:49

Trying to verify the attached SIL program with Silicon, I get the failure message

- all/basic11.sil [Silicon] *** FAILED ***
  semper.silicon.reporting.Z3InteractionFailed: Unexpected output of Z3. Expected 'success' but found: (error "line 88 column 90: unknown function/constant nil<Natural~List<Any>>")
  at semper.silicon.decider.Z3ProverStdIO.readSuccess(Z3ProverStdIO.scala:214)
  โ€ฆ

The version of Z3 in use here is 4.3.2.327b2bbe9ce9 for Ubuntu x86 unstable from 26 July 2013.

I have 5 other program examples which fail to verify with the same message. What these programs have in common is the use of the domain Any in a universal quantification. Programs not making use of Any like this do not seem to suffer from this kind of failure.

In the method property11 of the attached example, if the type List[Any] of xs is replaced by List[Natural], then the program verifies. So the following method is verified by Silicon.

method property11SpecialCase()
  ensures forall xs: List[Natural] :: drop(zero(), xs) == xs
{ }

Attachments:

Merging permission for aliases does not seem to work

Created by bitbucket user stefanheule on 2012-12-15 10:15
Last updated on 2014-03-18 08:54

The following Chalice method does not verify in Silicon.

:::scala
    method deAlias(x : C, y : C)
        requires x != null && rd(x.f)
        requires y != null && rd(y.f)
        ensures x == y ==> acc(x.f,2*rd) // IgnoreError 330: BUG: This method cannot be verified by Silicon currently (see <https://github.com/viperproject/silicon/issues/8>)
        ensures x != y ==> rd(x.f) && rd(y.f)
    {
    }

The test-case translation/CornerCases/deAlias includes this (with an IgnoreError).

NPE when trying to read preamble.

Created by bitbucket user bbrodowsky on 2013-05-05 11:57
Last updated on 2013-05-06 12:42

When scala2sil is run, a nullpointer exception is thrown when Silicon tries to read the preamble. For example:

[info] - http://pmbuilds.inf.ethz.ch/job/scala2sil/ws/target/scala-2.10/test-classes/translation/Assignments.scala [Silicon] *** FAILED ***
[info] java.lang.NullPointerException:
[info] at java.io.Reader.(Unknown Source)
[info] at java.io.InputStreamReader.(Unknown Source)
[info] at scala.io.BufferedSource.reader(BufferedSource.scala:22)
[info] at scala.io.BufferedSource.bufferedReader(BufferedSource.scala:23)
[info] at scala.io.BufferedSource.scala$io$BufferedSource$$charReader$lzycompute(BufferedSource.scala:33)
[info] at scala.io.BufferedSource.scala$io$BufferedSource$$charReader(BufferedSource.scala:31)
[info] at scala.io.BufferedSource$BufferedLineIterator.(BufferedSource.scala:61)
[info] at scala.io.BufferedSource.getLines(BufferedSource.scala:81)
[info] at semper.silicon.decider.DefaultDecider.readPreamble(Decider.scala:149)
[info] at semper.silicon.decider.DefaultDecider.pushPreamble(Decider.scala:130)

Incompletness with permissions under conditionals

Created by bitbucket user stefanheule on 2012-12-28 22:29
Last updated on 2014-03-18 07:25

There seems to be a problem with permissions under conditionals, as is illustrated by the testcase benchmark/Heaps/aliasing_iff.chalice. There are a number of unexpected errors.


Attachments:

Supporting epsilon permissions

Created by @mschwerhoff on 2013-05-25 13:33
Last updated on 2014-02-13 07:31

Epsilon permissions are currently not supported by Silicon, because it is not sure whether we'll keep them or not. If the decision to keep them is made, I'll add the support.

Incorrect evaluation of OR

Created by @mschwerhoff on 2013-09-22 22:28
Last updated on 2013-09-22 22:41

This example verifies, although it shouldn't:

method test01(x: Int, y: Int, z: Int)
  requires (z == x || z == y)
{
  assert z == y
}

I briefly looked at the smtlib2 output and the error seems to be related to the short-circuiting evaluation of OR.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.