[klee-dev] Confusions about coreutils experiments

Cristian Cadar c.cadar at imperial.ac.uk
Fri Nov 8 11:10:22 GMT 2013


Hi Hongxu,

You would need to debug the __overflow issue; could you also open an 
issue on GitHub?

It is important to read the info on that webpage and follow the 
instructions there.  Coverage numbers were obtained using replay+gcov, 
as mentioned in the paper.  (The KLEE stats are at the level of bitcode, 
and also refer to library code.)  Lei Zhang submitted a useful patch 
that makes replaying easier; I still need to review it, but you can find 
it at https://github.com/ccadar/klee/pull/31.   There are also other 
issues to take care when using gcov -- e.g, gcov doesn't record coverage 
on _exit -- which might require small adjustments.

Cristian

On 05/11/2013 10:00, Hongxu Chen wrote:
> Hi,
>
>     I'm trying to reproduce the coreutils results in klee08 paper(klee
> "make check" has been passed).
>
>     We were following KLEE "Coreutils Experiments"
> page(http://ccadar.github.io/klee/CoreutilsExperiments.html). And the
> major variants are:
>
> 1. used KLEE svn r165499 rather than revisions before r161056, and I got
> STP from KLEE "Getting Started"
> page(http://ccadar.github.io/klee/GetStarted.html).
> 2. used coreutils-6.10 rather than 6.11.
> 3. didn't use "--environ=test.env" and "--run-in=/tmp/sandbox"; also
> customized a "--output-dir" option. (I guess these are really trivial
> changes)
>
>     The 89 cases are running on a x86_64 machine whose OS is ubuntu12.04
> LTS. And here is some extra information about it:
>
> 1. > sudo fdisk -l
>
> Disk /dev/sda: 250.0 GB, 250000000000 bytes
> 255 heads, 63 sectors/track, 30394 cylinders, total 488281250 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00039844
>
>     Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *        2048   480026623   240012288   83  Linux
> /dev/sda2       480028670   488280063     4125697    5  Extended
> /dev/sda5       480028672   488280063     4125696   82  Linux swap / Solaris
>
> 2.  > grep "model name" /proc/cpuinfo
> model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
> model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
>
> We ran the cases for 3 times, and it took several days(sorry I didn't
> get the exact hours); I noticed some results with the help of
> "klee-stats --print-all" for each case:
>
> 1. There are several "*.external.err", and the failed external calls are
> "__overflow" and "__uflow".  they both result from
> "/usr/include/bits/stdio.h" of Line 66, however I didn't find any
> defitinition of them.
>
> 2. For those cases that KLEE halts without any external function fail, I
> find KLEE halt mainly because they are timed-out(I infer this since the
> "Time" results are typically a bit larger than "3600"). Should I
> increase the "--max-time" number?
>
> 3. The *ICov* and *BCov* I run isn't quite high(the highest are about
> 45% and 35% respectively). Should I trust the statistics or I am using
> the wrong results?
>
> 4.  "TSolver" still occupies most of the time(most of them are above 98%
> and the lowest is 95.23%).
>
> I believe I must have missed something and might have configured
> incorrectly.
>
> So I really need your kind help; any advice will be appreciated, thanks
> in advance!
>
> Best Regards,
> Hongxu Chen
>
>
>
>
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>




More information about the klee-dev mailing list