On Handling Source Code Positions and Local Variables in LTL

Software Model Checking

Guillaume H

etier and Hanifa Boucheneb

Laboratoire VeriForm, Department of Computer Engeneering and Software Engeneering,

Ecole Polytechnique de Montr

eal,

Montreal, Canada

Keywords:

Model Checking, Concurrency, C, Speciﬁcation, Veriﬁcation, Instrumentation, LTL, Assertions.

Abstract:

Software model checking techniques can provide the guaranty a system respects a speciﬁcation. However,

some limitations reduce the expressiveness of the most used speciﬁcation formalisms (the assertions and LTL)

and increase the risk of error, especially for concurrent programs. We design a new speciﬁcation formalism

that extends LTL by allowing local variables and code positions in LTL atomic propositions. We introduce

validity areas to extend the deﬁnition of atomic propositions using local variables and to handle positions in

source code. Then, we introduce a source to source transformation that aims to reduce the LTL veriﬁcation

problem to an assertion veriﬁcation problem for ﬁnite programs by building the product between the program

code source and the implementation of B

uchi automaton. Eventually, we apply this transformation to verify a

small benchmark speciﬁed with the speciﬁcation formalism we proposed.

1 INTRODUCTION

Safety and security of critical systems are issues of

prime importance. Formal methods aim to provide

mathematical proofs that such systems behave as ex-

pected. However, they still struggle to scale to large

systems. Improving tool performances is one of the

main focuses of current research activities.

A crucial point for formal methods is the speciﬁ-

cation of the system. In order to prove a system cor-

rectness, one must ﬁrst explain what it means for this

system to be correct in a formalism understandable

by tools. An error in the speciﬁcation may lead to

an invalid result: a correct proof of an unwanted re-

sult. Therefore, speciﬁcation formalism must be user-

friendly to reduce the risk of errors while being ex-

pressive enough to describe the system properties and

features.

In this paper, we focus on a speciﬁc formal met-

hod: software model checking. More precisely, we re-

strict our study to software model checking tools that

target C concurrent programs (based on the pThread

POSIX library). The two main speciﬁcation forma-

lisms supported by software model checking tools are

assertions and Linear Temporal Logic (LTL). Howe-

ver, their power of expression is limited. It is often ne-

cessary to modify the code of the program to express a

property. Assertions express safety properties: some

expression must be true when the assertion is reached

during the execution of a program. It is not possible

to specify a relation (order, simultaneity. . . ) between

events with assertions. For instance, in a concurrent

context, ensuring some instructions are executed in

a speciﬁc order is a non-trivial property that is often

desirable to verify. However this property cannot be

speciﬁed directly with assertions: additional code is

necessary to keep track of the order of instructions.

On the other hand, LTL may seem a better ﬁt for this

situation: it is designed to express properties about

the order of events in an execution trace. However

software model checkers do not allow the use of local

variables and source code positions in LTL speciﬁca-

tion. This restriction makes it impossible to represent

an assertion or to designate a set of instructions with

an LTL speciﬁcation, without additional code.

Mutual exclusion properties are a good example

where those limitations make the speciﬁcation less

straightforward. Remarks that in the listings 1 and

2, global variables have to be inserted in the code for

the need of speciﬁcation: it is easy to make an error in

this manual instrumentation or to forget to instrument

one section of the code.

Hétier, G. and Boucheneb, H.

On Handling Source Code Positions and Local Variables in LTL Software Model Checking.

DOI: 10.5220/0006865706150622

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 615-622

ISBN: 978-989-758-320-9

615

Listing 1: Mutual exclusion speciﬁcation with assertions.

i n t p = 0 ;

i n t f l a g = 0 ;

v o i d ∗ t h r e a d 1 ( v o i d ∗ d ) {

. . .

a s s e r t ( ! f l a g ) ;

f l a g = 1 ;

p += 1 ;

f l a g = 0 ;

. . .

}

v o i d ∗ t h r e a d 2 ( v o i d ∗ d ) {

. . .

a s s e r t ( ! f l a g ) ;

f l a g = 1 ;

p += 1 ;

f l a g = 0 ;

. . .

}

Listing 2: Mutual exclusion speciﬁcation with LTL.

/ / LTL : G ! ( f l a g 1 && f l a g 2 )

i n t p = 0 ;

i n t f l a g 1 = 0 ;

i n t f l a g 2 = 0 ;

v o i d ∗ t h r e a d 1 ( v o i d ∗ d ) {

. . .

f l a g 1 = 1 ;

p += 1 ;

f l a g 1 = 0 ;

. . .

}

v o i d ∗ t h r e a d 2 ( v o i d ∗ d ) {

. . .

f l a g 2 = 1 ;

p += 1 ;

f l a g 2 = 0 ;

. . .

}

In this paper, we introduce an extension of LTL

aiming to overcome these limitations by bringing the

support for local variables and source code positions

in LTL formula, by using the concept of validity areas.

Then, in order to verify whether a program respect a

speciﬁcation in the proposed formalism, we present a

source to source transformation that reduces LTL ve-

riﬁcation to assertion veriﬁcation on the transformed

programs, in the restricted context of terminating pro-

grams.

2 PRELIMINARIES

2.1 Software Model Checking

Software model checking is a class of formal methods

that allow to prove whether a model of a program sa-

Code Model

Speciﬁcation

Model checker

Figure 1: Principle of software model checking.

tisﬁes a speciﬁcation or not. In this context, the pro-

gram is abstracted in a transition system where states

represent the conﬁguration of the program memory

(or a position in the program) while transitions bet-

ween states represent the effect of instructions. The

speciﬁcity of software model checking is that the mo-

del is automatically extracted from the source code of

a program, without human intervention. The speciﬁ-

cation is a logical property. Model checking consists

in exploring exhaustively the reachable states of the

model in order to check whether every path satisﬁes

the speciﬁcation.

The main issue of software model checking is

combinatorial explosion. The number of states in a

model increases exponentially with the size of the

program: the time and memory required to explore

every state quickly become too important to complete

the exploration. This problem is even more present

for concurrent programs where every interleaving bet-

ween threads has to be considered. Several algorithms

(D’Silva et al., ) and reduction techniques have been

developed in order to ﬁght combinatorial explosion.

They often trade precision or completeness for per-

formances and limit themselves to speciﬁc categories

of properties.

Different formalisms are used to express a speci-

ﬁcation. Two of the most popular and the most used

by model checkers for concurrent programs are asser-

tions and LTL formulas.

2.2 Linear Temporal Logic (LTL)

Linear temporal logic allows to express logical pro-

perties over the evolution of a system, represented by

an execution trace.

Formally, let AP be a set of atomic propositions

over the state of the system, and Σ = 2

an alphabet.

Each letter of Σ represents a possibly empty set of

atomic propositions. We deﬁne inﬁnite traces as Σ

A trace a = (a

, a

, ...) ∈ Σ

represent the evolution

of an execution.

We deﬁne inductively LTL by the following gram-

mar, for φ and ψ two LTL formulas and p ∈ AP an

atomic proposition:

ICSOFT 2018 - 13th International Conference on Software Technologies

616

φ, ψ := true | p |φ ∧ ψ|¬φ|Xφ|ψUφ

Given an inﬁnite trace a = (a

, a

, ...) ∈ Σ

, LTL

has the following semantics :

s |= p ≡ s

|= p (1)

s |= Xφ ≡ (s

, s

, . . . ) |= φ (2)

s |= φUψ ≡ ∃k, (s

, s

k+1

, . . . ) |= ψ

∧∀i <= k, (s

, s

i+1

, . . . ) |= φ

(3)

¬, ∧, and true are interpreted in the usual way. Xφ

means the next state of the trace satisfy φ and φUψ

means the states of the trace must satisfy φ until one

state satisfy φ.

The operators F and G are then deﬁned as F p ≡

trueU p and Gp ≡ ¬F¬p. F express the fact an ato-

mic proposition is eventually true and G express the

fact it is always true.

LTL is mainly limited by the restrictions impo-

sed over atomic propositions: global variables do not

allow formulas to be expressive enough. Software

model-checking tools usually allow an atomic propo-

sition to be any side effect free boolean expression on

global variables. Allowing local variables and code

positions in LTL formulas would improve LTL ex-

pressiveness.

3 HANDLING LOCAL VARIABLE

AND CODE SOURCES

POSITIONS

Several issues must be overcome to allow local varia-

bles and code position in a LTL speciﬁcation. These

issues have been previously avoided by restricting

atomic proposition to global variable.

3.1 Handling Local Variable

Global variables are uniquely named in a program,

so their name is enough to refer to them without am-

biguity. However, the name only does not allow to

identify unambiguously a local variable.

• First, local variables in different contexts can

share the same name. In order to identify them

uniquely, a commonly used solution is to pre-

ﬁx the name of the variable with the name of

the function: for instance, the variable foo in a

function bar can be designated by bar::foo.

• Second, several instances of the same local vari-

able (from the same lexical deﬁnition) can coex-

ist in the memory. It happens for local variable

in recursive functions or when several threads are

executing the same code. In this situation, varia-

ble instances are deﬁned dynamically therefore it

is difﬁcult to designate them in a static way. We

do not propose a solution to this issue. We present

a partial solution implemented by the model chec-

ker Divine (Barnat et al., 2013) in the section 5.

3.2 Handling Code Source Positions

In order to use code source positions in the speciﬁ-

cation, we need a way to designate a position that is

both robust, user-friendly, and precise enough. An

external mechanism, such as using line numbers is

not robust: any modiﬁcation of the code source could

break the speciﬁcation. Therefore, we use marks in

the source code. We choose labels as they are part of

the C language and are already designed to mark an

instruction.

Further on, we say that a program reach a code

position when an instruction pointer of the program

point on the instruction designated by the label.

Next, we need to integrate code source locations

to the LTL speciﬁcation. Three options may be consi-

dered:

1) an atomic proposition is either a position or a

condition on the program variable, on an exclu-

sive way. For instance, if pos1 and pos2 repre-

sent two positions in the program, we specify the

variable x is not null between pos1 and pos2 by

G({pos1} =⇒ {x 6= 0}U{pos2}).

2) an atomic proposition is composed of both a con-

dition on the program variables and an infor-

mation about positions. The previous example

would become G¬p, where p is the atomic pro-

position true for every state between pos1 and

pos2 and where x is null. We could write p as

{x! = 0} ∧[pos1, pos2] with the convention an in-

terval of positions is evaluated to true when an

instruction pointer designates an instruction bet-

ween the two positions.

3) position information are constraints applied to

temporal operators, in a similar way than the MTL

logic (Koymans, 1990). We would then write

[pos1, pos2]

¬{x 6= 0}.

We rejected the third option to preserve the stan-

dard behavior of LTL operators.

3.3 Extending LTL Atomic Propositions

An atomic proposition of a LTL formula is intrinsi-

cally global: for every state s of the program (i.e. a

conﬁguration of the program memory and a set of va-

lues for instruction pointers), it may be necessary to

On Handling Source Code Positions and Local Variables in LTL Software Model Checking

617

evaluate whether s verify the atomic proposition. This

depends upon the value of a boolean expression in the

state s, evaluated using the value of variable in the

state s.

However, when this expression use local varia-

bles, it can only be evaluated in a state s where all

those local variables are deﬁned. Therefore, an ato-

mic proposition is correctly deﬁned only in the con-

text where all its variables are deﬁned (are not out of

scope). In order to get a valid deﬁnition of an atomic

proposition involving local variable, it is necessary to

extend its deﬁnition to the whole set of program sta-

tes.

3.4 Syntax and Semantics of the

Proposed Speciﬁcation

3.4.1 Syntax

Our speciﬁcation is composed of a standard LTL for-

mula and the deﬁnition of the atomic propositions that

are used. Atomic propositions are composed of the

following parts:

• a name: it is the identiﬁer of the atomic proposi-

tion.

• a validity area: it deﬁnes a block of instructions.

A validity area is deﬁned by two labels. Every

instruction pointer that reach the entry label must

reach the end label before it exits the context (a

branching instruction must not allow to go out of

the validity area while avoiding the exit label).

• an evaluation function: the name of a pure bool-

ean C function. This function is used to decide

whether a program state in the validity area verify

the atomic proposition. Its parameters are provi-

ded, in order, by the parameter list.

• a parameter list, to specify the variables to trans-

mit to the evaluation function. Every parameter

has to be deﬁned in the validity area.

• a default value: an atomic proposition takes its

default value out of its validity area.

The Table 1 presents the grammar of an atomic

proposition.

3.4.2 Semantics

Classic logic operators and temporal operators follow

the usual semantics of propositional logic and LTL.

An atomic proposition p is evaluated in a state s by:

• if the state s is not in the validity area of the atomic

proposition p, then p takes its default value.

• if the state s is in the validity area of the ato-

mic proposition p, then p takes the value returned

by the evaluation of its evaluation function in the

state s.

Validity areas have a double interest. The user can

specify manually where an evaluation function should

be used. He can exclude variable initializations and

other areas where program invariants are temporarily

broken. Moreover, validity areas allow to specify pro-

perties about intervals of program positions directly

in atomic propositions. It reduces the complexity of

the LTL formula, which improves the performances

of the veriﬁcation task.

Our speciﬁcation is a weaker restriction of LTL

than the one used by most model checkers, so expres-

sing an LTL formula on global variables only is trivial

(validity areas are the whole program). It is also pos-

sible to express assertions: it can be represented by

the formula Gp with p a proposition atomic such as its

validity area is the position of the assertion only, with

true as a default value and the expression in the asser-

tion as an evaluation function. Therefore, our speciﬁ-

cation formalism allows to express both the classical

version of LTL and assertions, while being capable to

specify directly properties such as mutual exclusion.

The listings 3 and 4 show how the presented for-

malism can be used to specify a mutual exclusion pro-

perty. No additional variable is needed. In this exam-

ple, the evaluation function does not depend of the

value of the variables, which explains why parameter

lists are empty in the speciﬁcation.

Listing 3: Code with critical areas delimited using labels.

i n t p = 0 ;

i n t f e v ( ) { re t u r n 1 ; }

v o i d ∗ t h r e a d 1 ( v o i d ∗ d ) {

. . .

b p1 :

p += 1 ;

e p 1 : ;

. . .

}

v o i d ∗ t h r e a d 2 ( v o i d ∗ d ) {

. . .

b p2 :

p += 1 ;

e p 2 : ;

. . .

}

ICSOFT 2018 - 13th International Conference on Software Technologies

618

Table 1: Grammar of atomic propositions.

<atomic-proposition> ::= <proposition-id> <evaluation-function> <parameters>

<proposition-id> ::= name of the proposition

<evaluation-function> ::= C pure boolean function

<parameters> ::= <parameter> <parameters> | nil

<global-parameter> ::= variable name

<local-parameter> ::= function name :: variable name

<default> ::= boolean

<validity-area> ::= <label> <label>

<label> ::= name of a C label

Listing 4: Speciﬁcation for a mutual exclusion property.

{ ” l t l ” : ”G( ! ( p1 && p2 ) ) ” ,

” pa ” : [

{” name ” : ” p1 ” ,

” d e f a u l t ” : f a l s e ,

” e x p r ” : ” f e v ” ,

” s p a n ” : [ ” b p 1 ” , ” e p 1 ” ] ,

” para ms ” : [ ]

} ,

{ ” name ” : ” p2 ” ,

” d e f a u l t ” : f a l s e ,

” e x p r ” : ” f e v ” ,

” s p a n ” : [ ” b p 2 ” , ” e p 2 ” ] ,

” para ms ” : [ ]

}

]

}

4 LTL TO ASSERTIONS

Most of the existing model checker for concurrent C

programs only accept assertions as speciﬁcation and

do not support LTL. To adapt one of these tools or to

create a new one would have been a task far beyond

the scope of this work. Instead, we designed a source

to source translation. From a code source and a spe-

ciﬁcation in the formalism presented in section 3, we

build a program speciﬁed with assertions. The trans-

formation respect the following invariant: “the obtai-

ned program satisfy the assertion if and only if the

initial program satisfy its speciﬁcation”.

4.1 Transformation Desing

The classic algorithm for LTL model checking con-

sists in building the product between a model of the

system and a B

uchi automaton representing the nega-

tion of the LTL speciﬁcation. The model checker then

explores the product: every valid path that reach an

accepting cycle corresponds to an execution violating

the speciﬁcation and is reported as an error.

Our transformation reuse this scheme with one

major difference, as presented in (Morse et al., 2015):

instead of building the product between the model of

the system and the B

uchi automaton, we implement

the B

uchi automaton in C and we build its product

with the code of the system. Thus, we obtain a new

code which contains the automaton and that can be

explored by most model checking tools.

The global organization of our transformation is

presented in Figure 2.

4.1.1 Implementing the B

uchi Automaton

We use LTL2BA (Gastin and Oddoux, ), an efﬁcient

and well-known tool, to compute the structure of the

uchi automaton from the LTL formula. Then, we

need to translate the automaton to C code. The trans-

formation uses the following elements:

• a global variable representing the current state of

the automaton

• a set of boolean variables representing the current

valuation of atomic propositions

• a function implementing the transition function of

the automaton. Every call to this function allows

the automaton to take a transition (if several tran-

sitions are possible, a non-deterministic choice is

made).

4.1.2 Build the Product

The next step is to synchronize the execution of the

program with the B

uchi automaton. We instrument

the program with instructions that update the values

of atomic propositions and trigger transitions in the

automaton. It would be useless and inefﬁcient to in-

strument every instruction of the program. We only

need to instrument instructions that could modify an

atomic proposition value: the entrance and exit in a

validity area, and the assignment of a parameter of the

evaluation function inside the validity area are the ﬁrst

candidates. Assignments to global variables out of

On Handling Source Code Positions and Local Variables in LTL Software Model Checking

619

Code

Product

Speciﬁcation (Φ) Automaton (¬Φ) Automaton code

Model checker

Correct

Error

Figure 2: Organization of the source to source transformation.

validity areas must also be instrumented: they could

have an impact on the valuation of an atomic propo-

sition when another thread is in the validity area. In-

strumentation is placed in atomic blocks to avoid the

generation of additional interleaving. Examples of in-

strumentation can be found on the repository of the

project: https://github.com/xNephe/baProduct.

4.1.3 Extract the Results

The last step is to use assertions to signal the model

checker when an error state is reached during the ex-

ploration. This can be done easily when it is possible

to know in a ﬁnite time whether the execution trace

is valid or not. However, when it is not possible, it

is extremely difﬁcult to detect a cycle in the program

from the inside of itself. To avoid this problem, we

limit ourselves to terminating programs, where every

execution terminates. This raise another issue: LTL

is only deﬁned on inﬁnite traces. Although several

extensions of LTL to ﬁnite traces exist (Beer et al., ),

none make consensus. Here, we use the stuttering ex-

tension, that consists in making a ﬁnite trace inﬁnite

by repeating its last state: it matches well a program

behavior, where the notion of next state is not preci-

sely deﬁned. Also, a program can easily be assumed

to stay in its last state indeﬁnitely at the end of the

execution.

Given the inﬁnite extension, we can now deter-

mine whether a ﬁnite trace is accepted by precompu-

ting the result for every state and every conﬁguration

of atomic properties. To make a distinction between

the results obtained using only a ﬁnite preﬁx of the

trace and those that make use of the inﬁnite extension

(and so may be different with another trace sufﬁx), we

use a four valuated logic. The possible outcomes are:

• VALID SURE: the automaton rejects the execu-

tion trace for every extension

• VALID MAYBE: the automaton rejects the exe-

cution trace for the stuttering extension but may

accept it with another extension

• ERROR MAYBE: the automaton accepts the exe-

cution trace for the stuttering extension but may

reject it with another extension

• ERROR SURE: the automaton accepts the execu-

tion trace for every extension

4.1.4 Implementation

We implemented a tool to produce this instru-

mentation, available at https://github.com/xNephe/

baProduct. The tool is implemented in OCaml (Leroy

et al., 2016) and use the CIL library to instrument the

code. B

uchi automatons are produced using LTL2BA

(Gastin and Oddoux, ).

4.2 Experimental Results

We tested the presented tool and speciﬁcation for-

malism on a benchmark of tests (available with the

tool). It consists on 11 small scenarios (less than

100 line each) implementing common concurrent pat-

terns (producer-consumer, data race, answer on re-

quest, road signals. . . ). The tests focus on concur-

rency and errors related to the misuse of synchroniza-

tion primitives. We used two bounded model checkers

as backends to perform veriﬁcation tasks over the in-

strumented code, ESBMC 4.2 (Cordeiro et al., ) and

CBMC 5.7 (Clarke et al., ), running on a computer

with a processor Intel Core i7 (4 cores at 3.7GHz,

6 Go of RAM and Fedora 25 (64 bits). The tables

2 and 3 summarize the results we obtained.

We observe that ESBMC and CBMC succeed in

most of the veriﬁcation tasks, although some unex-

pected results are observed: ESBMC ﬁnd an error in

a valid test case and CBMC miss an error in an inva-

lid test case. As far as we can tell, these behaviors are

not triggered by an error in the transformation. They

may be related to a loss of precision due to perfor-

mance optimizations in the backend model checkers.

ESBMC fails on the test battery var as well after ha-

ving used all the available memory.

Performance measurements show that CBMC is

much more efﬁcient than ESBMC on this benchmark.

We explain this difference by the different algorithms

used to handle concurrency: ESBMC explores every

interleaving independently while CBMC builds a sin-

gle veriﬁcation goal integrating all interleaving. Most

ICSOFT 2018 - 13th International Conference on Software Technologies

620

Table 2: Results of the veriﬁcation of an instrumented benchmark.

Test scenario CBMC ESBMC Expected result

answer simple ERROR MAYBE ERROR MAYBE ERROR MAYBE

answer simple valid ERROR MAYBE VALID MAYBE VALID MAYBE

battery simple ERROR SURE ERROR SURE ERROR SURE

battery var ERROR SURE Runtime error ERROR SURE

crossing exclusive green VALID MAYBE VALID MAYBE VALID MAYBE

crossing exclusive mutex VALID MAYBE VALID MAYBE VALID MAYBE

crossing GF green ERROR MAYBE ERROR MAYBE ERROR MAYBE

crossing order VALID MAYBE VALID MAYBE VALID MAYBE

prod cons mutex VALID MAYBE VALID MAYBE VALID MAYBE

prod cons simple ERROR SURE VALID SURE ERROR SURE

race ERROR MAYBE ERROR MAYBE ERROR MAYBE

of our tests consist on ﬁnding a speciﬁc interleaving,

which is more compatible with CBMC approach.

5 RELATED WORK

5.1 Support of Local Variable in LTL

Divine is a model checker for concurrent C programs

which supports LTL speciﬁcations. In (Barnat et al.,

), a formalism supporting local variables and positi-

ons in the program in LTL speciﬁcation is presented.

It is based on a set of macros that allow to modify di-

rectly the value of an atomic proposition in the code

and to bind an expression (containing or not local va-

riables) to an atomic proposition in a lexical context.

This approach allows to express atomic propositions

in a more intuitive manner at the cost of being more

invasive in the code source. However, they do not in-

troduce the concept of validity areas: it is more com-

plicated to restrict the use of an evaluation function to

speciﬁc instructions, and relations between values of

variables and positions in the code has to be realized

in the LTL formula, which increases its complexity.

A partial solution to the issue of the identiﬁcation

of local variable in recursive functions or threads is

also introduced. Using the fact that most of the time,

the interesting event is when an atomic proposition ta-

kes its non-default value, their solution is to compute

the valuation of the atomic proposition in every pos-

sible context and to keep the non-default value if it is

produced at least once. This solution corresponds to

the expected behavior for safety or reachability pro-

perties. However it is an arbitrary decision in general.

5.2 Reduction of LTL Speciﬁcation to

Assertions

We based our source to source transformation on the

work of J.Morse, in (Morse et al., 2015). However, in

this work, the automaton is implemented in an addi-

tional thread, that behave as an observer. In order to

avoid the generation of many interleavings, a model

checker speciﬁc instruction is used, that allows con-

text switch to the observer thread at speciﬁc position

of the code only. By using a function instead of a

thread, our version avoid the use of this model chec-

ker speciﬁc instruction and remains compatible with

several tools.

6 CONCLUSION

In this paper, we highlighted some of the limitations

of two of the most used speciﬁcation formalism in the

context of concurrent C programs. We proposed a

new speciﬁcation formalism based on LTL that ans-

wer to those limitations thanks to the concept of vali-

dity areas: this mechanism allows to handle both local

variables and code positions in an LTL speciﬁcation.

Then, in order to test the proposed formalism, we pre-

sent a source to source transformation that reduce the

problem of LTL veriﬁcation to the veriﬁcation of as-

sertion for terminating programs and we implement it

in a tool.

However, our speciﬁcation formalism may not be

intuitive to write, which could be improved in a fu-

ture work. Moreover, the instrumentation and code

transformation we propose does not use any reduction

technique, which limits it to very small programs. The

addition of partial order reductions taking into ac-

count the structure of the B

uchi automaton may im-

prove the performances. It would also be interesting

to implement the support for the proposed speciﬁca-

tion directly in a model checking tool. It would pro-

bably be possible to overcome the restriction to ter-

minating programs and to gain both in precision and

performances by doing so.

On Handling Source Code Positions and Local Variables in LTL Software Model Checking

621

Table 3: Performances of the veriﬁcation of an instrumented benchmark.

CBMC ESBMC

Test scenario Time (s) Memory (MB) Time (s) Memory (MB)

answer simple 0.87 42 5.57 56

answer simple valid 0.81 41 12.91 72

battery simple 1.07 42 13.95 61

battery var 666.04 954 N/A OOM

crossing exclusive green 2.93 44 32.12 119

crossing exclusive mutex 1.73 44 32.20 120

crossing GF green 1.99 46 41.70 117

crossing order 1.02 40 11.62 56

prod cons mutex 10,046.32 593 229.99 28

prod cons simple 1.70 52 454.00 2711

race 1.08 41 5.65 28

REFERENCES

Barnat, J., Brim, L., Havel, V., Havl

cek, J., Kriho, J.,

Len

co, M., Ro

ckai, P.,

Still, V., and Weiser, J. (2013).

DiVinE 3.0 – An Explicit-State Model Checker for

Multithreaded C & C++ Programs. In Computer Ai-

ded Veriﬁcation (CAV 2013), volume 8044 of LNCS,

pages 863–868. Springer.

Barnat, J., Brim, L., and Rockai, P. Towards LTL model

checking of unmodiﬁed thread-based c c++ programs.

In Lecture Notes in Computer Science (including sub-

series Lecture Notes in Artiﬁcial Intelligence and Lec-

ture Notes in Bioinformatics), volume 7226 LNCS,

pages 252 – 266.

Beer, I., Ben-David, S., and Landver, A. On-the-ﬂy model

checking of RCTL formulas. In Proceedings of the

10th International Conference on Computer Aided Ve-

riﬁcation, CAV ’98, pages 184–194. Springer-Verlag.

Clarke, E., Kroening, D., and Lerda, F. A tool for checking

ANSI-c programs. In Tools and Algorithms for the

Construction and Analysis of Systems, pages 168–176.

Springer, Berlin, Heidelberg. DOI: 10.1007/978-3-

540-24730-2 15.

Cordeiro, L., Morse, J., Nicole, D., and Fischer, B. Context-

bounded model checking with ESBMC 1.17 (compe-

tition contribution). In Lecture Notes in Computer

Science (including subseries Lecture Notes in Artiﬁ-

cial Intelligence and Lecture Notes in Bioinformatics),

volume 7214 LNCS, pages 534 – 537.

D’Silva, V., Kroening, D., and Weissenbacher, G. A survey

of automated techniques for formal software veriﬁca-

tion. 27(7):1165–1178.

Gastin, P. and Oddoux, D. Fast LTL to b

uchi automata

translation. In Computer Aided Veriﬁcation, pages 53–

65. Springer, Berlin, Heidelberg.

Koymans, R. (1990). Specifying real-time properties with

metric temporal logic. Real-time systems, 2(4):255–

299.

Leroy, X., Doligez, D., Frisch, A., Garrigue, J., R

emy, D.,

and Vouillon, J. (2016). The OCaml system (release

4.04): Documentation and user’s manual. Institut Na-

tional de Recherche en Informatique et en Automati-

que.

Morse, J., Cordeiro, L., Nicole, D., and Fischer, B. (2015).

Model checking ltl properties over ansi-c programs

with bounded traces. Software & Systems Modeling,

14(1):65–81.

ICSOFT 2018 - 13th International Conference on Software Technologies

622