P.D. Reiter

pdreiter ·

Chris and I worked through a similar problem in the issue I opened in response to this gitq:There’s a bug in the docker api that isn’t closed yet because they needed to resolve win vs Linux issue. If you pull in the docker api fix into your virtual env are...

Did your bug scenario build its bugzoo cont... correctly?You should have followed the directions from here: to add the and build the via .You may also want to run the on your to make sure that the code coverage that Darjeeling uses is generated correctly.

Great! Thanks @ChrisTimperley - that worked perfectly.

I was able to duplicate the scenario where not only do I see different candidates from the STDOUT Darjeeling repair, but also some different repairs.
I launched a few back to back darjeeling runs like so with the :

for i in $(seq 0 1 10); do 
    mkd...

...and that's it. i'm new to automake (as in this is the first time I've ever done it) and it looks like I have to always pass these flags via configure.

BUT I'm not seeing how I can tell BugZoo YML file to pass in these flags as a baseline compile for

Okay, figured out the problem, but not sure why it's happening yet.I also should have noticed it earlier, but I'll blame that on rushing to the airport and then the plane. Basically the Makefile isn't getting regenerated/overwritten with the where have...

You’re totally right - haven’t injected that code yet. I’ll try that ASAP.
The program I’m working on required clang-7 and libcstd++-8 (for c++17 compatibility), and some other packages. Probably the root of the issue :-/

I launched a bugzoo container and manually launched the --coverage with the configuration command and didn’t run into the linking issue.

Looking at the bugzoo log, it looks like the file-with-instrumentation was manipulated. Is that correct? If so, How ...

and the docker container does have the gcov lib:

docker@d79f9349bbbf:/experiment/src$ find / -type f -name "libgcov.a"
/usr/lib/gcc/x86_64-linux-gnu/8/libgcov.a
/usr/lib/gcc/x86_64-linux-gnu/7/libgcov.a

@ChrisTimperley - let me double check that this was what I was seeing a couple of weeks ago. if I confirm, I'll promote this to an issue. cool?

Regardless, determining if the port is being used by another service (and whether the service is a bugzoo server) is probably good error checking to have.When I saw this behavior and looked at the ephemeral invocation, my head immediately went to solution ...

I had two different xterms in two different directories invoking two different bugzoo programs with darjeeling.While one darjeeling invocation died like the logs I shared, the other found a repair.At this point in time, I have only seen that error once - I...

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 is supplied to the compiler command line and that used by , the following er...

It looks like amending line.decode('utf-8').rstrip('\n') from mgr/container.py to include "backslashreplace", allowed bugzoo bug validate <mybug> to pass test cases:

579         for line in out:
580             line = line.decode('utf-8',"backslashreplace...

I was able to duplicate the exact repair as the exhaustive search by adding a conjunction with len(lines_changed)>0 to if not any(line in test_line_coverage for line in lines_changed) : from evaluator.py : _filter_redundant_tests

123     def _filter_red...

...and it looks like all tests are being filtered out in this candidate (zero-mutations) scenario.

# select a subset of tests to use for this evaluation
         tests, remainder = self._select_tests()
         logger.info("[ALL] tests = [%s] for candid...

I added some debug information to print out more information about the candidate patch [mostly in the evaluator.py] - and it looks like the test list is empty for the candidate that's being posed as the solution:

finished waiting for pending evaluations...

Looks like this falls back into my issue - since I didn't have a specific Makefile for compiling this code, but instead the Makefile was for running , was grabbing the coverage files. with the Makefile infrastructure change, it's looking better now! As ...

great!
I'm seeing from ManyBugs pull request #16 that this is simply bear make -j4.
I'll try this out.
thanks @ChrisTimperley!

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,...

- 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 addresse...

Good to know! As for the output log file name, think how you implemented it for bugzoo is perfectly fine for darjeeling.

Soooo, my getting rid of the stale and wrong cached coverage file, I was able to get the coverage generated correctly.

It would be nice for BugZoo to let the user know that it is using a cached version of the coverage for that test.