graph
graph copied to clipboard
labeled_graph::remove_vertex does not remove label
When calling remove_vertex
on a labeled_graph
the vertex is removed but the label is not.
A dangling reference to the vertex is left behind. Accessing it causes segfaults.
Minimal example:
#include <iostream>
#include <string>
#include <boost/graph/directed_graph.hpp>
#include <boost/graph/labeled_graph.hpp>
using namespace boost;
using namespace std;
int main() {
using namespace boost::graph_detail;
typedef directed_graph<> Digraph;
typedef labeled_graph<Digraph, string> Graph;
Graph g;
g.add_vertex("foo");
auto v = g.vertex("foo");
if(v != nullptr)
cout << "foo exists\n";
g.remove_vertex("foo");
auto v2 = g.vertex("foo");
if(v2 != nullptr)
std::cout << " BUG! vertex label still exists.\n";
return 0;
}
@jzmaddock Hey, this looks like a good one for me to work on.
Go for it!
@arneboe Can I get your full name and email, since what you submitted is what I'm basing the regression test on? I need to credit you.
I dont care about the credit, but if you have to: Arne Böckmann
It looks like the intended design, given the state of BGL, is to have _map
a protected member, not a private member. So you hack was less of a hack than was expected.
This may take longer than expected: https://github.com/boostorg/graph/blob/develop/include/boost/graph/adjacency_matrix.hpp#L992
May be related: https://svn.boost.org/trac10/ticket/7863
This is going to be delayed somewhat. There are general cleanups in testing which I need to do first.
Sure, take your time! Better have it fixed correctly and thoroughly, than to rush it and only come up with some quick'n'dirty patch that fails somewhere else.
Just an update, had to move twice, once across states, and started a new job. Getting back to this more now.
Alright, no pressure. Just don't forget it ;-)
And... it was forgotten This bug really tripped me up when I tried to use labeled_graph
As it seems... @anadon how's it going?
Not sure if they are still active on Boost.Graph, but if someone submits a pull request to fix this issue, I can help them get it polished and merge it.
Hey there, any update on it? @anadon by any chance do you still have your WIP PR that people can pick up from?
This may be related:
There was a patch at https://svn.boost.org/trac/boost/ticket/9493 (I did not create it) which is no longer reachable, but I've been using it in production for years
I've preserved it here: https://github.com/DeuceBox/graph/commit/de651cb06cd92d59effed88ae0fc79852c43ff34
It appears to fix the bug in the minimal example given in the OP.
@DeuceBox @jeremy-murphy Is there currently an active pull request introducing the fix referenced by @DeuceBox?
Facing the same issue and would appreciate the fix being shipped with the stock boost library.
@StahlTim @jeremy-murphy since there wasn't any real discussion beyond the branch/fix I linked a while back, I've put in a PR.
I'll prioritise merging in the fix asap.
Could someone please check out the fix I just merged and test it? Thanks to @DeuceBox for making the PR.
Hi @jeremy-murphy, has this fix already been merged somewhere? I can't find it in the latest release
@EduardoGoulart1 It's merged here https://github.com/boostorg/graph/pull/354 in the "develop" branch. The boostorg/graph "develop" branch is what the boostorg/boost "master" branch references. However, the latest boostorg/boost release branch/tag (boost-1.85.0) references the corresponding release tag in boostorg/graph (https://github.com/boostorg/graph/releases/tag/boost-1.85.0), but it appears based on https://github.com/boostorg/graph/tags that the boostorg/graph repo's release tags haven't pointed to anything new since 2022.
@jeremy-murphy could we get the next boostorg/graph release tag to reference a more recent version of develop? I don't know what's involved in that process.
Thanks for pointing it out. That's about how long I've been maintainer for and I'm still learning what needs to be done! I assumed all that release tag business would be automatic from the super project.