Re: [Boost-users] [BGL] memory leak in graph/r_c_shortest_paths.hpp

Subject: Re: [Boost-users] [BGL] memory leak in graph/r_c_shortest_paths.hpp
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2013-09-23 11:31:45

On Mon, 23 Sep 2013, potato_research wrote:

> Hello,
>
> I'm using BGL in my project and, with some input data, I get - sooner or
> later, as I run r_c_shortest_paths many times - a segfault.
>
> This behaviour is apparently quite random, as I can see by implementing a
> custom visitor that the last label evaluated before the crash changes all
> the time. I must also say that the graph I use, while always having the same
> topological structure, has different properties that affect labelling each
> time I run the algorithm and these vary quite randomly from one run to the
> other, as they are generated by a random heuristics.
>
> Anyway, with one particular set of input data, I manage to have the program
> segfault (as I said, sooner or later) 100% of the times. This is far from
> being an MWE, but it's the best I could produce.

Could you please try the version that is in the trunk now?  I added a 
bunch of assertions to try to diagnose this issue.

> I tried to debug the memory leak with valgrind and it turns out that
> r_c_shortest_paths_dispatch is trying to access memory in a block previously
> freed by:
>
> l_alloc.deallocate( cur_outer_splabel.get(), 1 );
>
> in r_c_shortest_paths.hpp:314. After some debugging I started to believe
> that the problem doesn't rely with my code, but it might be a bug in
> r_c_shortest_paths.hpp. If this is actually the case and where the problem
> lies, though, I haven't been able to figure out with certainty.
>
> The output from valgrind can be found here:
> http://pastebin.com/raw.php?i=WWafwFv3 (output cleaned up and with templates
> substituted)
> http://pastebin.com/raw.php?i=cb3p6jzM (raw output intended to facilitate
> reading and with templates substituted)
> http://pastebin.com/raw.php?i=qeauBQTm (raw output indented to facilitate
> reading)
> http://pastebin.com/raw.php?i=hpppf49c (raw output)
>
> My code (the whole project) can be found here:
> https://github.com/alberto-santini/maritime-vrp
>
> In order to run it, one must have a licensed copy of CPLEX and change the
> include and library paths in the Makefile's accordingly. Unfortunately,
> without putting the labelling part inside a price-and-branch procedure (that
> uses CPLEX as a solver for the master problem) I wasn't able to produce
> input data by hand that would lead me to obtain the segfault.

Can you dump each set of input data before it goes into 
r_c_shortest_paths, then send whichever version causes it to fail?

-- Jeremiah Willcock