The caller object eats much memory

Hi I’d like to explore all paths of a give fuction, so I choose the caller object. The tested code is a simple bubble sort, shown as follows.

#define BUFF_LEN 6
void bubble_sort(char *buff)
{
  for(int i = 0; i < BUFF_LEN - 1; i++)
    for(int j = i + 1; j < BUFF_LEN; j++)
    {
       if(buff[i] > buff[j])
       { 
         int tmp = buff[i];
         buff[i] = buff[j];
         buff[j] = tmp;
       }
    }
}

Then length of buffis 6, so I suppose there would be thousands of paths at most. Below is my testing script.

import angr
b = angr.Project("path_explosion")
cfg = b.analyses.CFGAccurate()
target_func = cfg.kb.functions.function(name='bubble_sort')
print target_func
p = b.factory.path()
x = p.state.memory.load(0x1000, 6)
c = b.surveyors.Caller(0x400566, (0x1000, ), start=p)#0x400566 is the entry of bubble_sort 
print tuple(c.iter_returns())
print c

I installed Angr in a virtual machine. Before running the testing script, 4.1GB physical memory are cost (8GB in total). The memory consumption increases to 8GB in a few seconds, after I launch the script. After a few minutes, Angr cashes due to memory exhaustion (may be).

Then I change the length of buffinto a little bit smaller value, that is 5. Angr gives me result in about 3 minutes as follows (I omitted detailed information of all founded paths for brief). <Explorer with paths: 0 active, 0 spilled, 798 deadended, 0 errored, 0 unconstrained, 226 found, 0 avoided, 0 deviating, 0 looping, 0 lost>

I suppose that the caller object may eat much memory if there are many paths (thousands?) should be explored.

[zardus]

lol. For testing purposes, you can also spin up some pretty beefy instances on AWS. But I’d also check out veritesting. It can be used by passing enable_veritesting=True to the PathGroup creation.

[zardus]

I think it’s also important to note that there’s a middle ground between “symbolic execution is the panacea of program analysis” and “symbolic execution is useless”. One of the approaches that @rhelmot talks about in the 32C3 talk is Veritesting (see: https://users.ece.cmu.edu/~aavgerin/papers/veritesting-icse-2014.pdf). angr includes an implementation of this, and it might actually help in this case.

In general, though, 8 gigs is very little memory. IMO, 32 gigs is too little for reasonable programs. My workstation for angr, for example, has 128 gigs.