On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote: > "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > ... > > Since you're working on the weekend ;-), here are some > notices I'd begun to accumulate: > > There are a bunch of new uses of open64, which isn't portable. > How about using AC_SYS_LARGEFILE in configure.in instead? > Then you can use "open" everywhere. > > In storage_backend_loop.c, it looks like vol->target.path can be leaked. Which function is that in ? Since originally writing it I've changed all error path cleanup code to simply call virStorageVolDefFree(), so there's a central function which will free all members, rather than having cleanup duplicated all over the place. > Just after that, I wondered if other vol->members could be leaked, > but haven't yet looked at the cleanup-called vol-destroying > function; it probably frees everything. Yep, check virStorageVolDefFree() - that's intended to be the only place where vol->members are cleaned up. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list