Fix potential unsafe initialization in the Graph class#606
Conversation
Signed-off-by: Carlos Agüero <caguero@openrobotics.org>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #606 +/- ##
=======================================
Coverage 95.97% 95.98%
=======================================
Files 147 147
Lines 10122 10130 +8
=======================================
+ Hits 9715 9723 +8
Misses 407 407 ☔ View full report in Codecov by Sentry. |
| std::cerr << "[Graph::AddVertex()] The limit of vertices has been " | ||
| << "reached. Ignoring vertex." << std::endl; | ||
| return Vertex<V>::NullVertex; | ||
| return NullVertex<V>(); |
There was a problem hiding this comment.
this seems like an API change; we may need to do it, but let me check if sdformat will be affected
There was a problem hiding this comment.
yes, this will require changes in sdformat:
https://github.com/gazebosim/sdformat/blob/main/src/FrameSemantics.cc#L89
There was a problem hiding this comment.
I restored the original static members and added deprecations. It should be possible to keep using them.
15b8975
scpeters
left a comment
There was a problem hiding this comment.
we should update the migration guide to document the API break / deprecation, depending on which route we take
| std::cerr << "[Graph::AddVertex()] The limit of vertices has been " | ||
| << "reached. Ignoring vertex." << std::endl; | ||
| return Vertex<V>::NullVertex; | ||
| return NullVertex<V>(); |
There was a problem hiding this comment.
yes, this will require changes in sdformat:
https://github.com/gazebosim/sdformat/blob/main/src/FrameSemantics.cc#L89
| class UndirectedEdge : public Edge<E> | ||
| { | ||
| /// \brief An invalid undirected edge. | ||
| public: static UndirectedEdge<E> NullEdge; |
There was a problem hiding this comment.
We may choose to make a hard API break here, but I'd prefer to not remove these static types in this pull request, but to deprecate them instead, so that we can coordinate fixes for sdformat and any other gz-* packages in separate pull requests.
There was a problem hiding this comment.
Let me know if the changes in 15b8975 are sufficient to keep sdformat and friends compiling.
There was a problem hiding this comment.
it looks like sdformat15 will still compile with this change as of 5f606f0 (tested using the ci_matching_branch/ trick partially documented in gazebosim/docs#377)
https://build.osrfoundation.org/view/gz-ionic/job/sdformat15-install_bottle-homebrew-amd64/210/
Signed-off-by: Carlos Agüero <caguero@openrobotics.org>
Signed-off-by: Carlos Agüero <caguero@openrobotics.org>
Migration.md
Outdated
| + The functions `Graph::AddEdge()`, `Graph::LinkEdge()`, | ||
| `Graph::EdgeFromVertices()` and `Graph::EdgeFromId()` functions might | ||
| return NullEdge() instead of NullEdge. | ||
| E.g.: https://github.com/gazebosim/gz-math/pull/606/files#diff-0c0220a7e72be70337975433eeddc3f5e072ade5cd80dfb1ac03da233c39c983L222-R222 |
There was a problem hiding this comment.
I don't think these are breaking change in Graph.hh. I had originall commented on Graph.hh because that is where I noticed that our API was changing due to the previously removed type, but for this PR, I think the only needed change to the Migration guide is the deprecations below
There was a problem hiding this comment.
You're right, we're not changing the function signature so it should be fine.
Co-authored-by: Steve Peters <scpeters@openrobotics.org> Signed-off-by: Carlos Agüero <cen.aguero@gmail.com>
This reverts commit 17585a9. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
This reverts commit 17585a9. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
| { | ||
| static auto e = std::make_unique<EdgeType>( | ||
| VertexId_P(kNullId, kNullId), E(), 1.0, kNullId); | ||
| return *e; |
There was a problem hiding this comment.
looking at Material::Predefined(), I wonder if the unique pointer should be made and released from inside a static lambda function?
There was a problem hiding this comment.
I think it would be better to use gz::utils::NeverDestroyed (e.g. https://github.com/gazebosim/sdformat/blob/f05f4e7ad1a6784f9ff1a6c1b362191677baa70d/src/Types.cc#L149). However, the fact that this function returns a non-const reference could be problematic since anyone can modify the value.
There was a problem hiding this comment.
regarding the non-const reference, I think the behavior in gz-math7 and earlier with static variables has a similar issue right? I tried changing the NullEdge and NullVertex functions to return a const reference, but lots of Graph.hh functions that currently return non-const references like to return references to NullEdge or NullVertex and fail to compile. This seems like a bigger issue with the API that we could open an issue about.
* Avoid constructor/destructor fiascos in graph class * Deprecations and migration guide. Signed-off-by: Carlos Agüero <caguero@openrobotics.org> Signed-off-by: Carlos Agüero <cen.aguero@gmail.com> Co-authored-by: Steve Peters <scpeters@openrobotics.org>
🦟 Bug fix
Partially fixes #269 (
Graphclass).Summary
I implemented the "Construct on first use" idiom (https://www.freecodecamp.org/news/cpp-static-initialization-order-fiasco/) to avoid the potential unsafe construction.
Checklist
codecheckpassed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-bymessages.