-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
INTEGRATION_world_clone failures can leave rogue gzserver processes #1299
Comments
Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero). It could potentially kill the future options of running all the tests in parallel using different gzservers or run manually gazebo while the test suite is being run. I would prefer to figure out a way of clean up only after the clone test and don't close the door to potential parallelization. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). An alternative that we use when spawning other |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). We haven't released the code in the default branch yet, so we could also just change the message if that was easier. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I just had another thought about the first idea of trying to kill rogue gzserver processes. When I
With some careful filtering, we should be able to terminate With regard to running multiple test suites in parallel, I'm pretty sure two world_clone tests could not be run in parallel since the test has a hard-coded port number. We would need to give each instance a unique number. |
Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero). If we are able to determine which gzserver was spawned by the world_clone test, I think that this would be ideal. Parallel testing is still not on the table, but a nice idea to work on. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). The following would be a workaround until the ServerControl message is modified:
To test, apply the following:
and run this command:
I'll make a pull request for this when I have a chance. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). It looks like there was another failure even after the fix from pull request #1232: http://build.osrfoundation.org/job/gazebo-default-devel-trusty-amd64-gpu-nvidia/127/consoleFull |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
This wasn't fixed entirely, since there is a bug in pull request #1232 |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I found the bug from a test log on my machine, viewable at https://gist.github.com/scpeters/a355665271490e81c381 There seems to be an issue with my regex for extracting the process id (pid), which was assuming no whitespace at the beginning of the line (which can happen actually if the pid has a small number of digits compared to other pid's). Fix is forthcoming in branch issue_1299. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
for the second time: pull request #1334 |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I just saw another failure. I had to |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
we need to do |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
The
INTEGRATION_world_clone
test spawns externalgzserver
processes and then tears them down (see world_clone.cc:199). If the test has an internal failure, it might not reach the point where it terminates the externalgzserver
process. This has happened two times recently, and it causes all the other tests to fail:Should we update the tool/check_test_ran.py to kill any external gzserver instances that it sees?
The text was updated successfully, but these errors were encountered: