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