-
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
SimbodyLink::GetWorldAngularVel and others are not thread safe #918
Comments
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). Sometimes I see failures more when running the executable multiple times, rather than using --gtest_repeat. Also, it didn't have a display, so I don't know if that matters as well. |
Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu). tried with display off
test fails:
got a core file:
Looks like |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I just caught a core file in my overnight testing.
Failing thread:
Test thread:
Full backtrace:
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). Two of the Jenkins failures were on default, my overnight test was on gz_tool_part1 branch (a00b5c0), which is branched from default as well. I'm not sure if it happens on gazebo_2.1 at all. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). try locking physics update mutex in LinkState::Load? |
Original comment by Michael Sherman (Bitbucket: sherm1). Per discussion at this morning's meeting: to me this looks like a timing problem -- it appears that thread 1 (testing thread) tried to pull something out of the same state that thread 27 (simulation thread) was writing on. It is thread 1 that failed. This error message is a pretty good clue:
Looks like the stage advanced between the time the stage check failed and the time when the error message was formatted, indicating that another thread was writing to it. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
|
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I've updated the title, since I believe that it is assumed that the gazebo physics API functions are thread-safe, and that some of the SimbodyPhysics functions are not. To illustrate this, I added a test for thread safety in 8ba87c2 (branch issue_918). The test starts up a world with a bunch of pendulums and un-throttles it so it runs as fast as it can. Then in the testing thread, The Link::GetWorldLinearVel and Link::GetWorldAngularVel functions are called repeatedly. The simbody incarnation of this test fails immediately. |
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters). I expanded the test a bit and added a fix in 179a8cf. |
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 John Hsu (Bitbucket: hsu, GitHub: hsu).
The text was updated successfully, but these errors were encountered: