Spinroot

A forum for Spin users

You are not logged in.

#1 Re: General » How to verify a simple safety property? » 2012-04-23 08:11:25

Ok, thank you. I have reduced my example like you proposed (I compare with 7 then) and then the verification works with and without -DBITSTATE but I still have a question. Refering to my initial example:

How can the verification result depend on the complexity of the problem (assuming unlimited memory and time)? I have not limited the search depth or time (at least not explicitely) so I think I'am doing an exhaustive verification. I don't see any spin output indicating a limited search. Do I have to trigger an exhaustive search explictely or is it a feature of -DBITSTATE not to be exhaustive?

#2 General » How to verify a simple safety property? » 2012-04-20 13:28:25

Gordon
Replies: 3

Hi,

I'am using spin version 6.1.0 on Windows and tried to verify a simple safety property. Therefore I run spin with the -a flag and compile the generated pan.c file with the switches -DBITSTATE -DSAFETY. When I run the verification of the example below, the result (if an counter example was found or not) depends on several settings.

- If the compile switch SAFETY is used or not
- if the variable 'r1' is at the global scope or in the scope of process 'all'
- the data type of the variable 'NR1' (bool or int)

I'am a bit confused about this. It seems to me that in some settings a full verifaction is not done although I run the verifier in this mode (I do not use any options when running the generated verifier).

Could you please have a look at my small piece of promela code and give me some hints what I'am doing wrong here?


Here is the promela code:


int REG_2;
hidden int TMP_VALUE;
byte MEMORY[2];
int NR1 = 0;
byte r1;

init
{
  atomic {
    run all();
  }
}

inline write() {
  select(r1: 0..255);
  MEMORY[0] = r1;

  select(r1: 0..255);
  MEMORY[1] = r1;
}


proctype all()
{
  write();
  d_step {
    TMP_VALUE = (MEMORY[0] << 8);
    TMP_VALUE = (TMP_VALUE | MEMORY[1]);
    REG_2 = TMP_VALUE;
  }
  write();
  if
    ::(REG_2 != 42) ->   goto BB0_2;
    ::else -> skip
  fi;

  NR1 = 1;

BB0_2:
    skip;
}

never {
    do
       ::skip
       ::NR1 == 1 -> break;
    od;
}

#3 Re: Bug Reports » Error parsing -2147483648 » 2011-07-14 08:33:52

Fine. It is important for a verification tool to be correct. So i am looking forward for a fixed version of spin. I have the windows version of spin (compiled with cl). Does the unix/linux version parse the number correctly? If atoi is called with 2147483648 i don't know how this could work on unix/linux. If the unix atoi flags an error it would'nt correct the result. Atoi has no chance to give the correct answer because the answer does not fit into 32bit. However, thank you for the support. The important point is, that this error should be fixed somewhere.

#4 Re: Bug Reports » Error parsing -2147483648 » 2011-07-13 08:30:36

Dear Administrator,

I don't doubt that the behaviour of atoi is like you described it. However x = -2147483648 is a valid promela statement with the semantics, that x becomes -2147483648. I had a look into the grammar and lex part of spin (Version 6.10) and believe that the bug is within the lexer. The token "-2147483648" is NOT recognized as a CONST. Instead the lexer recognizes '-' and than '2147483648' as two separate tokens. The grammar rule for expr than creates an atoi call for 2147483648 (which is not defined but returns MAX_INT). the minus is applied later and leads to the described behaviour. So you have to to fix the lexer!

#5 Re: Bug Reports » Error parsing -2147483648 » 2011-07-12 16:38:22

Hi,

I think you can not blame atoi for this bug. The atoi function might have been called with the sign which would not lead to this behaviour.
Atoi("2147483648") is not a valid test case for this issue. 2147483648 has NO representation in signed 32bit (-2147483648 does). Atoi("-2147483648") will hopefully lead to the expected result. So the bug is most probably in the call of atoi.

#6 Bug Reports » Error parsing -2147483648 » 2011-07-12 07:09:31

Gordon
Replies: 7

The promela parser seems not to read the smallest integer value (32 bit) correctly. In the following example spin will print out
-2147483647.


int v;

proctype all() {
  v = -2147483648;
  printf("%d\n", v);
}
init
{
run all();
}

Board footer

Powered by FluxBB