On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote:
"Daniel P. Berrange" <berrange@redhat.com> 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 -=|