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