Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

kaskara-statement-finder : "Compile command not found" #6

#1

I'm trying to debug my toy source code where there are 0 snippets and 0 statements and I'm reusing the debug methodology from an earlier interaction with @ChrisTimperley.
Basically, kaskara-statement-finder (and kaskara-loop-finder) does not seem to work - instead getting "Compile command not found." as the output from this command.

(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.fauxware$ cat check_kaskara.py && echo "------" && python3 check_kaskara.py 
import kaskara
import bugzoo.server

with bugzoo.server.ephemeral() as client_bugzoo:
    snapshot = client_bugzoo.bugs['sefcom:fauxware']
    files = ['/experiment/src/fauxware.c']
    kaskara.Analysis.build(client_bugzoo, snapshot, files)
------
[kaskara.analysis] build
[kaskara.analysis] build : try
building statement database for snapshot [%s] sefcom:fauxware
fetching statements from files: %s /experiment/src/fauxware.c
executing statement finder [/experiment/src]: kaskara-statement-finder /experiment/src/fauxware.c
executed statement finder [0]:
  Skipping /experiment/src/fauxware.c. Compile command not found.
reading statement analysis results from file: %s statements.json
finished reading statement analysis results
[kaskara.analysis] build : return
(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.fauxware$

This is consistent with the darjeeling repair sample.yml command output:

(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.fauxware$ darjeeling repair sample.yml 
destroying existing patch directory
/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/darjeeling/cli/__init__.py:102: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  yml = yaml.load(f)
search will terminate when an acceptable patch has been discovered
using threads specified by configuration: 16 threads
using time limit specified by configuration: 3600 minutes
using candidate limit specified by configuration: 5000 candidates
using random number generator seed provided by configuration: 0
using language: c
using repair settings: Settings(use_scope_checking=True, use_syntax_scope_checking=True, ignore_dead_code=True, ignore_equivalent_appends=True, ignore_untyped_returns=True, ignore_string_equivalent_snippets=True, ignore_decls=True, only_insert_executed_code=True)
connecting to BugZoo server
connected to BugZoo server
computing coverage information...
computed coverage information
computing fault localization...
supported suspiciousness metrics: genprog, tarantula, ochiai, jaccard, ample
using suspiciousness metric: tarantula
computed fault localization:
Localization(
  fauxware.c:10: 0.50;
  fauxware.c:13: 0.50;
  fauxware.c:17: 0.50;
  fauxware.c:27: 0.53;
  fauxware.c:29: 0.53;
  fauxware.c:30: 0.53;
  fauxware.c:38: 0.50;
  fauxware.c:44: 0.50;
  fauxware.c:45: 0.50;
  fauxware.c:47: 0.50;
  fauxware.c:48: 0.50;
  fauxware.c:49: 0.50;
  fauxware.c:50: 0.50;
  fauxware.c:51: 0.50;
  fauxware.c:52: 0.50;
  fauxware.c:54: 0.50;
  fauxware.c:55: 0.50;
  fauxware.c:57: 0.53)
[kaskara.analysis] build
[kaskara.analysis] build : try
building statement database for snapshot [%s] sefcom:fauxware
fetching statements from files: %s fauxware.c
executing statement finder [/experiment/src]: kaskara-statement-finder fauxware.c
executed statement finder [0]:
  Skipping /experiment/src/fauxware.c. Compile command not found.
reading statement analysis results from file: %s statements.json
finished reading statement analysis results
[kaskara.analysis] build : return
determined passing and failing tests
* passing tests: p16, p14, p10, p12, p13, p4, p6, p9, p2, p5, p7, p1, p8, p3, p15, p11
* failing tests: n1, n2
ordering test cases
test order: n2, n1, p14, p5, p15, p13, p4, p6, p11, p3, p8, p2, p10, p16, p9, p1, p12, p7
constructing database of donor snippets...
constructed database of donor snippets: 0 snippets
constructing transformation database...
constructed transformation database: 0 transformations
beginning search process...
all candidate patches have been exhausted
failed to find a patch
waiting for pending evaluations to complete.
finished waiting for pending evaluations to complete.
found 0 plausible patches
time taken: 0.00 minutes
# test evaluations: 0
# candidate evaluations: 0
  • replies 7
  • views 5.2K
  • likes 1

@ChrisTimperley - Could I also get the set of commands I need to run to get kaskara to build locally? I have been using the included dockerfile as my template, but there's something missing in my local environment that the docker image from christimperley/clang addresses that I can't figure out from the stack overflow comment.

#3

@pdreiter Has fauxware changed since you last sent it to me? I notice a Dockerfile.old in the tea_sampler.fauxware, but no Dockerfile. Is that fine?

#4

Yeah, that version of the infrastructure is quite out of date. I know I changed the yml to explicit gcc compile instead of using the Makefile and potentially other stuff - and I’m not certain that version of the Dockerfile ever worked. Unfortunately, I’m out of the office right now without access to my workstation, returning 6/23. I’m sorry, I should have thought ahead and tarballed the latest and greatest version, sending it to you.
However, I think you could potentially leverage your same kaskara debug methodology from our earlier debug session and push the fauxware.c file to a bugzoo container. I had a similar failure with kaskara-loop-finder, so this should also work.

$ docker create --name kaskara squareslab/kaskara
$ docker run --volumes-from kaskara --rm -it <some bug>
~ /opt/kaskara/scripts/kaskara-loop-finder /experiment/fauxware.c

while using another terminal to docker cp fauxware.c <id>:/experiment/fauxware.c to the running container.

-p

#5

I would expect to see the same error for any of the kaskara-* tools. Clang is complaining that it doesn't know how fauxware.c was used to compile the binary. Usually, for a single file program with a main function, Clang can figure out the structure of the program. For more complicated projects, Clang relys on the presence of a compile_commands.json file, typically produced by CMake (or bear).

To get things up and running, you could use bear to create a compile_commands.json file for the project.

#6

Looks like this falls back into my Makefile issue - since I didn't have a specific Makefile for compiling this code, but instead the Makefile was for running GenProg, bear make -j$(nproc) was grabbing the GenProg coverage files. with the Makefile infrastructure change, it's looking better now! As in, I now get a repair from Darjeeling for my toy problem!!

#8

hey @ChrisTimperley -
I ran into a similar failure with a little more complicated build environment - it looks like kaskara does not work with all command line switches.

When --save-temps is supplied to the compiler command line and that used by bear, the following error occurs:

docker@0be95d8ba664:/experiment/src$ /opt/kaskara/scripts/kaskara-statement-finder src/example_1.c 
error: unable to handle compilation, expected exactly one compiler job in ' "gcc" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-E" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "example_1.c" "-mrelocation-model" "pic" "-pic-level" "1" "-pic-is-pie" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/opt/kaskara/bin/../lib/clang/5.0.0" "-c-isystem" "." "-c-isystem" "/opt/kaskara/clang" "-cxx-isystem" "." "-cxx-isystem" "/opt/kaskara/clang" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/opt/kaskara/bin/../lib/clang/5.0.0/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/experiment/src" "-ferror-limit" "19" "-fmessage-length" "104" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-o" "example_1.i" "-x" "c" "src/example_1.c";  "gcc" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-fsyntax-only" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "example_1.c" "-mrelocation-model" "pic" "-pic-level" "1" "-pic-is-pie" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/opt/kaskara/bin/../lib/clang/5.0.0" "-fdebug-compilation-dir" "/experiment/src" "-ferror-limit" "19" "-fmessage-length" "104" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-disable-llvm-passes" "-x" "cpp-output" "example_1.i"; '
Error while processing /experiment/src/src/example_1.c.

By eliminating --save-temps, kaskara successfully completes. I'm also seeing darjeeling running nicely now, too.