Quoting Dwight Engen (dwight.en...@oracle.com): > Hi guys, > > So the line: > > r = lxc_grow_array((void ***)&h->all_mount_points, > &h->all_mount_point_capacity, k + 1, 4); > > in cgroup.c shows up in valgrind as a leak. I thought the appropriate > fix was: > > diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c > index e27bc03..c5dc7e2 100644 > --- a/src/lxc/cgroup.c > +++ b/src/lxc/cgroup.c > @@ -1563,6 +1563,7 @@ void lxc_cgroup_hierarchy_free(struct > cgroup_hierarchy *h) if (!h) > return; > lxc_free_array((void **)h->subsystems, free); > + lxc_free_array((void **)h->all_mount_points, free); > free(h); > } > > which does free the allocated memory, but then causes a segv the next > time free(line) in find_hierarchy_mountpts() is called. The trap is in > libc::malloc_consolidate() so I think there is heap corruption going > on. Any ideas?
Well the exact symptoms you describe are a bit fishy - I'd expect a double-free warning right at the line you added. I think you want to just free(h->all_mount_points). The all_mount_points[i] entries get set to 'mount_point' which are also pointed to by meta_data, and which you freed right before the loop calling lxc_cgroup_hierarchy_free(). Does just using free at this same spot fix it for you? -serge ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
