-
Notifications
You must be signed in to change notification settings - Fork 193
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
Provide more available error messaging for nonexistent and invalid frames in canTransform #187
Conversation
tf2/src/buffer_core.cpp
Outdated
@@ -853,15 +860,19 @@ bool BufferCore::canTransform(const std::string& target_frame, const std::string | |||
if (target_frame == source_frame) | |||
return true; | |||
|
|||
if (warnFrameId("canTransform argument target_frame", target_frame)) | |||
std::unique_lock<std::mutex> lock(frame_mutex_); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what are you locking here?
It's preferable locking in scopes to make this clear:
{
std::unique_lock<std::mutex> lock(frame_mutex_);
// ...
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I.e. could you validate w/o locking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is in the original, it's locking reading of the tf frame tree until the end of the function, for validateFrameId
and canTransformNoLock
. It shows up as a new line here because it was moved a few lines up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a risk of validateFrameId
to call back canTransform
? If we expect a lock to be held before validateFrameId
is called, shouldn't it be validateFrameIdNoLock
to align with canTransformNoLock
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not that validateFrameID has to have a lock held, but that we are pinning the two validation calls to the same version of the tf tree by acquiring the lock. This doesn't seem to be done in all places where two frames are looked up and then have their transforms checked, and the tree walk happens based on a TimePoint, so I don't think it's necessary. My next version only locks for the tree walk itself. Uploading momentarily
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new version looks better to me.
ee0fc37
to
4f4dca1
Compare
f4e2ffd
to
1ec9d3e
Compare
…n doing canTransform lookups Signed-off-by: Emerson Knapp <emerson.b.knapp@gmail.com>
Signed-off-by: Emerson Knapp <emerson.b.knapp@gmail.com>
1ec9d3e
to
10349e4
Compare
Second half of follow-through for #130
Part of fix for #118
Part of https://github.com/ros-security/aws-roadmap/issues/74
Signed-off-by: Emerson Knapp emerson.b.knapp@gmail.com