Opened 3 years ago

Last modified 8 weeks ago

#11723 new Bugs

Memory leak (and assertion failed) in r_c_shortest_paths.hpp

Reported by: a.santini@… 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)

boost_bug.cpp (7.5 KB) - added by a.santini@… 3 years ago.
boost_bug.cpp
graph.txt (76.8 KB) - added by a.santini@… 3 years ago.
graph.txt

Download all attachments as: .zip

Change History (6)

Changed 3 years ago by a.santini@…

Attachment: boost_bug.cpp added

boost_bug.cpp

Changed 3 years ago by a.santini@…

Attachment: graph.txt added

graph.txt

comment:1 Changed 3 years ago by a.santini@…

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 Changed 3 years ago by a.santini@…

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 Changed 3 years ago by anonymous

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.

comment:4 Changed 8 weeks ago by mateusz.polnik@…

Hi Jeremiah,

I created a pull request to the GitHub repository that fixes a memory leak in the algorithm for shortest paths with resource constraints.

Could you advise me what if there is anything I could do to have the pull request approved and merged in?

Linkto the pull request.

Note: See TracTickets for help on using tickets.