The bpf instruction gives the 'crash backtrace' information when handling loops about seahorn

[agurfinkel]

fixed in above commit. The issue was with not handling properly the case when optimization removes all basic blocks of the function.

[bfsyrgz]

example.c

#include  "seahorn/seahorn.h"

#define LIMIT1 1000
#define LIMIT2 1000

int count;
int *count_global_p = &count; 

void incr_count() {
  count++;
}

void doit(int i, int j) {
  if (i > j) {
    incr_count();
  }
}

int main() {
  int i = 0, j = 0;

  for (i = 0; i < LIMIT1; i++) {
    //storeGlobalVar
    int count_store = *count_global_p;
    
    //renameUsedVar
    int j_1 = j;
    int i_1 = i;
    
    //initial_loop
    for (j = 0; j < LIMIT2; j++) {
      doit(i, j);
    }
		
    //restoreGlobalVar
    *count_global_p = count_store;
    
    //same_loop
    for (j_1 = 0; j_1 < LIMIT2; j_1++) {
      doit(i_1, j_1);
    }
    
    //conditionStmt
    sassert(j == j_1) ;
    sassert(i == i_1) ;
  }

  return 0;
}

This example is still about "crash backtrace" message.

In example.c, the two inner for loops are equivalent in terms of the operation of the function doit(). The two statements int count_store = *count_global_p; and *count_global_p = count_store; are used to ensure that the global variable count has the same value before the two for loops.

I ran sea bpf example.c but got the unexpected "crash backtrace" message. (shown in this crash- backtrace.txt)

Please help me explain why this message appeares. Thanks.

[agurfinkel]

Unfortunately this is not something I will be able to fix (at least not quickly). The root cause of the problem is in LLVM's implementation of ScalarEvolution. It is implemented using recursion, and your program, when unrolled, is too big for the stack. Recursion runs out of stack and that causes a crash.

It works for LIMIT of 248 or below, and runs out of stack for higher limits on my machine.

Note that you really should not expect bounded model checker to work well on code that requires thousands of loop unrollings. Even if seahorn generates the verification condition, it will not be solvable, except for trivial instances.

If you are working on program equivalence, you should be looking into heuristics to break the problem into parts that can be shown equivalent in isolation. This is a strategy that tends to work well for hardware equivalence checking.

There has been number of works on applying similar techniques for software via what is called a self-composition of a program with itself, or slightly modified version of itself.