Chris Timperley

ChrisTimperley ·

Thanks for your interest in ROSWire! Support for ROS2 is planned for sometime this summer.

Apologies! It turns out that there was a bug in the time limit handling:

"Waiting for pending evaluations to complete" shouldn't take as long as that. (It usually takes a few minutes, depending on the bug that's being repaired.)

Can you CTRL+C/SIGTERM the Darjeeling process and upload the log file? I haven't come across this f...

@cjfgnsdk12 Unfortunately, there's a Windows vs. Linux compatibility issue in the DockerPy source code that causes this bug to manifest: https://github.com/docker/docker-py/issues/2278

There's a pending PR on the DockerPy repo that fixes this problem:

@cjfgnsdk12 @pdreiter The issue appears to be resolved. You'll need to git pull your copy of ManyBugs (https://github.com/squaresLab/ManyBugs) and then you'll need to rebuild any of the gzip images that you wish to repair (e.g., bugzoo bug build manyb...).

Ah. It looks like the Docker images for the scenarios don't have Bear. Going forward, the plan is to get Darjeeling to automatically run bear during a rebuild to obtain a , but for now, the quick fix is to add Bear to the Gzip images. I'll go ahead and do...

@cjfgnsdk12 @pdreiter I can confirm that I can reproduce your error on my machine. It appears that the BugZoo scenario is fine, but that the static analysis step (performed by Kaskara) is failing. I'm debugging the issue now.

(Also, thanks for respondin...

It looks like you've run into the problem of trying to interact with Docker whilst inside a Docker container. There are two common solutions to the problem. One solution is overkill and should be avoided at all costs (dind: Docker-in-Docker). The other...

It looks like your environment is setup correctly and that you have everything installed. The issue seems to be with the BugZoo bug scenario that you're trying to repair. Can you share the configuration file that you're using for Darjeeling?

Hi. I don't suppose that you could share some more details about the error?

Also, what versions of Docker and Python 3 are you using? And are you using pipenv or virtualenv to install Darjeeling? If you're not using either of those, I would recommend usin...

Fixed via https://github.com/squaresLab/Darjeeling/pull/138

It looks like this could be a clang/glibc issue. When you manually compiled, I'm guessing that you didn't manually inject the source code instrumentation that BugZoo/Darjeeling adds when computing coverage? https://github.com/squaresLab/BugZoo/blob/maste...

Awesome. Thanks!

The same set of mutations should be generated. If that's not the case, then it sounds like there's a bug.

So, by default, Darjeeling will spin up a temporary BugZoo server on a predetermined port. When the second Darjeeling instance is launched, it will try to launch a new BugZoo server on the same predetermined port that was used by the first Darjeeling...

I haven't tried to do this before, but so long as the Darjeeling instances are connected to different BugZoo servers, then this shouldn't be an issue. How did you launch the Darjeeling and BugZoo processes?

It looks like the problem here is in the static analysis component, Kaskara, rather than Darjeeling. For Kaskara issues, I would launch the container, mount the Kaskara binaries, and try to run kaskara-* on the source code.

If you simply want to find how ...

I would expect to see the same error for any of the tools. Clang is complaining that it doesn't know how 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 mor...

@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?

I don't think that Darjeeling is currently setup to write its logs to file. I could add a --log-to-file [FILENAME] option to the command line? Or do you have a better suggestion? Either way, I'm happy to implement that functionality.

From a quick glance, it looks like this is due to the Makefile. BugZoo calls the command correctly (take a look at ~/.bugzoo/logs to confirm), but the binary is destroyed after make is called (should clean_all be included in the all rule?)

I don't suppose that I can get access to your repository with fauxware? That will make debugging a little easier :-)
Alternatively, uploading sefcom:fauxware to DockerHub would also work.

This looks like a bug in BugZoo. Specifically, it looks like the context in test-harness is being ignored. Just to double check, ./test.sh works when you manually invoke it from inside /experiment/src?