[BGL] Assertion failed / memory leak in r_c_shortest_paths.hpp
In the following 2-years old thread, a memory leak was experienced when using r_c_shortest_paths of the boost graph library. Jeremiah Willcock added a bunch of assertions to the code, to help identify the problem. https://groups.google.com/forum/#!topic/boost-list/W1muJiw85pA I think I now have a reproducible version of this, which I believe might be a bug. I would like some input before opening a bug report. Here is the gist: https://gist.github.com/alberto-santini/32c19530dcefb784d0f2 It contains: 1) graph.txt which contains a dump of the graph that exposes the problem 2) boost_bug.cpp which is the code used to build the graph from file and do the labelling 3) terminal_output.txt which contains the command used to compile and what happens when running the code It has been tested on Mac OS X 10.11 with GCC 5.2 and Boost 1.58. The programme doesn't necessary trigger the assertion at each run. There are runs in which it completes successfully, runs in which it segfaults without triggering any assertion and times in which it's aborted by the failed assertion. The failed assertion is: Assertion failed: (p_cur_label->b_is_valid), function r_c_shortest_paths_dispatch, file /usr/local/include/boost/graph/r_c_shortest_paths.hpp, line 472. I would like to know if you experience the same behaviour and can confirm (or at least make an educated guess) wether or not this is a bug in r_c_shortest_paths.hpp. Thanks, AS
I am not sure this can help, but I added some debugging output to r_c_shortest_paths.hpp. Here are my findings. The assertion fails when reconstructing pareto-optimal paths by walking back through pareto-optimal labels, at the end of the labelling process. Walking back a pareto-optimal path: 4163 3567 Assertion failed: (p_cur_label->b_is_valid) Ok, so what is the parent of this label 3567, that causes the assertion to fail? New label 3567 is feasible and extends 3454 Ah-ah! And why is this label 3454 not valid? Deleting dominated label: 3454 (dominated by 17903) So, apparently a dominated label made it into a pareto-optimal path?! Find attached r_c_shortest_pats.hpp modified to print debug info.
participants (1)
-
Alberto Santini