You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
labeled_graph::remove_vertex does not remove label #167
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;
}
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.
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.
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.
@EduardoGoulart1 It's merged here #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.
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.
still have some bugs with graph vertex type boost:vecS
when remove a vertex in _graph . the index in _graph has been changed after remove . but _map still hold the old value
Just to drop in and mention I began to work on this. The test suite seems quite incomplete and I will first try to have better coverage of possible bugs before fixing anything 😄
After looking into it, it looks like a serpent nest: both labeled_graph and named_graph are incomplete and/or broken, and their implementation is problematic in multiple aspects (for example named_graph is a bit of a wart on adjacency_list: it's mixed in as a base class and drags in Boost.MultiIndex unconditionally, even for users who never touch named lookup)
Fixes are not trivial, so I provided an umbrella issue aiming at solving all of this at once #465 .
I will close this issues as it's being superseded by the umbrella issue.
Thanks again guys for this helpful discussion and analysis ❤️
Activity
anadon commentedon Apr 17, 2019
@jzmaddock Hey, this looks like a good one for me to work on.
jzmaddock commentedon Apr 17, 2019
Go for it!
anadon commentedon Apr 17, 2019
@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.
arneboe commentedon Apr 18, 2019
I dont care about the credit, but if you have to: Arne Böckmann
anadon commentedon Apr 18, 2019
It looks like the intended design, given the state of BGL, is to have
_mapa protected member, not a private member. So you hack was less of a hack than was expected.anadon commentedon Apr 18, 2019
This may take longer than expected: https://github.com/boostorg/graph/blob/develop/include/boost/graph/adjacency_matrix.hpp#L992
anadon commentedon Apr 18, 2019
May be related: https://svn.boost.org/trac10/ticket/7863
anadon commentedon Apr 24, 2019
This is going to be delayed somewhat. There are general cleanups in testing which I need to do first.
HWiese1980 commentedon Apr 24, 2019
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.
anadon commentedon Jul 11, 2019
Just an update, had to move twice, once across states, and started a new job. Getting back to this more now.
HWiese1980 commentedon Jul 24, 2019
Alright, no pressure. Just don't forget it ;-)
fjch1997 commentedon Jul 29, 2022
And... it was forgotten
This bug really tripped me up when I tried to use labeled_graph
HWiese1980 commentedon Jul 30, 2022
As it seems... @anadon how's it going?
jeremy-murphy commentedon Aug 1, 2022
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.
EGRCel commentedon Jun 29, 2023
Hey there, any update on it? @anadon by any chance do you still have your WIP PR that people can pick up from?
DeuceBox commentedon Jun 30, 2023
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:
DeuceBox@de651cb
It appears to fix the bug in the minimal example given in the OP.
StahlTim commentedon Nov 17, 2023
@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.
DeuceBox commentedon Nov 17, 2023
@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.
jeremy-murphy commentedon Nov 18, 2023
I'll prioritise merging in the fix asap.
jeremy-murphy commentedon Nov 28, 2023
Could someone please check out the fix I just merged and test it? Thanks to @DeuceBox for making the PR.
EGRCel commentedon Jul 26, 2024
Hi @jeremy-murphy, has this fix already been merged somewhere? I can't find it in the latest release
DeuceBox commentedon Jul 26, 2024
@EduardoGoulart1 It's merged here #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.
jeremy-murphy commentedon Jul 27, 2024
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.
IamHuskar commentedon Jul 3, 2025
still have some bugs with graph vertex type boost:vecS
when remove a vertex in _graph . the index in _graph has been changed after remove . but _map still hold the old value
Becheler commentedon Mar 30, 2026
Just to drop in and mention I began to work on this. The test suite seems quite incomplete and I will first try to have better coverage of possible bugs before fixing anything 😄
Becheler commentedon May 14, 2026
Hi people,
After looking into it, it looks like a serpent nest: both
labeled_graphandnamed_graphare incomplete and/or broken, and their implementation is problematic in multiple aspects (for examplenamed_graphis a bit of a wart on adjacency_list: it's mixed in as a base class and drags in Boost.MultiIndex unconditionally, even for users who never touch named lookup)Fixes are not trivial, so I provided an umbrella issue aiming at solving all of this at once #465 .
I will close this issues as it's being superseded by the umbrella issue.
Thanks again guys for this helpful discussion and analysis ❤️