Yes, the planner object contains the graph. Since the graph is declare inside the object I don't have to destroy it explicitely. right ? The following code is one thing I've tried, the first one I tried was to iterate on the and freeing the states, but didn't work... So here, first romove from the graph and the free the state. If no other solution I'll try to switch to boost::shared_ptr but I'd like to understand what's going on. thamk you for your quick answer ! class Sampling_solver{ public: int nbsample; Graph g; vertex_name_map_t v_name_map ; vertex_prop_map_t v_prop_map ; edge_weight_map_t e_weight_map; edge_name_map_t e_name_map ; state_vertex_map_t name_vertex_map; Sampling_solver(Model *m); ~Sampling_solver(){ graph_traits<Graph>::vertex_iterator vi, vi_end, next; tie(vi, vi_end) = vertices(g); for (next = vi; vi != vi_end; vi = next) { ++next; remove_vertex(*vi, g); free(v_name_map[*vi]); } g.clear(); }; Jeremiah Willcock a écrit :

On Mon, 4 Jan 2010, Matthieu BOUSSARD wrote:

...

Hello,

I'm using BGL to construct an exploration graph. At each decision step I have to create a new graph. It seems that I'm not freeing correctly the memory, causing a memory leak. The name of a node in the graph is a pointer to a structure,

typedef adjacency_list >, property > >Graph;

I also use a map to find the vertex according to a given state typedef std::tr1::unordered_map state_vertex_map_t;

In the destructor of my planner object, every time I try to free anything (from the map or from the vertices of the graph) I'v got an "double free or corruption" error. Could you help me to find the way to free all the memory ? Thank you.

Does your planner object contain the graph? When exactly is the property data destroyed relative to the graph itself? You might be better off using boost::shared_ptr as your property type; copies (and explicit deallocation) will no longer be a problem in that case.

-- Jeremiah Willcock _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Matthieu BOUSSARD Toyohashi University of Technology Department of Information and Computer Sciences Active Intelligent Systems Laboratory (Miura Laboratory) Toyohashi - Japan

The planner computes a behaviour, which I'm using to select the next action. Then I delete the solver (delete(solver)) and create a new one (new solver). I used valgrind to check memory leaks, and it seems that the states are not freed. I've set the environmment variable MALLOC_CHECK_ to 0 ignoring the double free error and use the following destructor ~Sampling_solver(){ for(state_vertex_map_t::iterator it=name_vertex_map.begin();it!=name_vertex_map.end();it++){ free(it->first); } } Then the memory leak desapears and the application (seems to) works fine. So I should really free the state in the destructor, but how? And yes, for once performance is critical, but if I don't have too much work to do for using the shared_ptr, I'll try. Matthieu Jeremiah Willcock a écrit :

On Mon, 4 Jan 2010, Matthieu BOUSSARD wrote:

...

Yes, the planner object contains the graph. Since the graph is declare inside the object I don't have to destroy it explicitely. right ?

The following code is one thing I've tried, the first one I tried was to iterate on the and freeing the states, but didn't work... So here, first romove from the graph and the free the state. If no other solution I'll try to switch to boost::shared_ptr but I'd like to understand what's going on. thamk you for your quick answer !

class Sampling_solver{ public: int nbsample; Graph g; vertex_name_map_t v_name_map ; vertex_prop_map_t v_prop_map ; edge_weight_map_t e_weight_map; edge_name_map_t e_name_map ; state_vertex_map_t name_vertex_map;

Sampling_solver(Model *m); ~Sampling_solver(){ graph_traits<Graph>::vertex_iterator vi, vi_end, next; tie(vi, vi_end) = vertices(g); for (next = vi; vi != vi_end; vi = next) { ++next; remove_vertex(*vi, g); free(v_name_map[*vi]); } g.clear(); };

Are you sure the solver object outlives the graph (and all copies of properties obtained from the graph)? Do you destroy the solver then use the results of the algorithm (that are state objects destroyed by the solver's destructor)? In any case, shared_ptr is a much simpler way to deal with the problem if performance is not critical.

-- Jeremiah Willcock _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Matthieu BOUSSARD Toyohashi University of Technology Department of Information and Computer Sciences Active Intelligent Systems Laboratory (Miura Laboratory) Toyohashi - Japan