Opened 7 years ago
Last modified 4 years ago
#11723 new Bugs
Memory leak (and assertion failed) in r_c_shortest_paths.hpp
| Reported by: | Owned by: | Jeremiah Willcock | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | graph |
| Version: | Boost 1.58.0 | Severity: | Problem |
| Keywords: | bgl, graph | Cc: |
Description
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. 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.
Attachments (2)
Change History (6)
by , 7 years ago
| Attachment: | boost_bug.cpp added |
|---|
comment:1 by , 7 years ago
I am not sure this can help, but I added some debugging output. Here are my findings. The assertion fails when reconstructing pareto-optimal paths by walking back through pareto-optimal labels. Output:
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?!
comment:2 by , 7 years ago
More insights (in case anyone will ever take care of this). I think the problem is the following: when a label L residing at a vertex V is dominated by a new label L', all unprocessed labels which have L as predecessor will now point to a deallocated L. I believe they should, instead, be rebased so to have L' as their predecessor.
It's not clear to me if such a situation (a label that has been extended is now dominated) is pathological or not.
See the modified r_c_shortest_paths.hpp here (grep for the parts nearby "\tWARNING"). This files prints to std::cerr some debug info.
comment:3 by , 7 years ago
To reply to my previous comment: it's not by itself pathological that label L is dominated; the problem is that all extensions of L' should dominate all extensions of L... therefore no extension of L should make it into the final pareto-optimal set of paths.
I will now try to understand whether this situation is due to a bad dominance criterion on my side (am I not honouring some requirement/precondition of the dominance operator? I have to say the related documentation *could* be better) or not.
boost_bug.cpp