-
Notifications
You must be signed in to change notification settings - Fork 497
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: