Coverity spotted the leaks. Here's a proposed fix. I didn't bother with a separate diagnostic for the unlikely event that we read a negative number from the pipe. Seems far-fetched enough not to bother, but it's easy to add, if anyone cares. From: Jim Meyering <meyering(a)redhat.com&gt; Date: Thu, 25 Feb 2010 19:24:50 +0100 Subject: [PATCH] openvzGetVEID: don't leak (memory + file descriptor) * src/openvz/openvz_conf.c (openvzGetVEID): Always call fclose. Diagnose parse failure also when vzlist output is empty. If somehow we read a -1, diagnose that (albeit as a parse failure). --- src/openvz/openvz_conf.c | 19 +++++++------------ 1 files changed, 7 insertions(+), 12 deletions(-) diff --git a/src/openvz/openvz_conf.c b/src/openvz/openvz_conf.c index ce0c4d3..3713a45 100644 --- a/src/openvz/openvz_conf.c +++ b/src/openvz/openvz_conf.c @@ -964,6 +964,7 @@ int openvzGetVEID(const char *name) { char *cmd; int veid; FILE *fp; + bool ok; if (virAsprintf(&cmd, "%s %s -ovpsid -H", VZLIST, name) < 0) { openvzError(NULL, VIR_ERR_INTERNAL_ERROR, "%s", @@ -979,18 +980,12 @@ int openvzGetVEID(const char *name) { return -1; } - if (fscanf(fp, "%d\n", &veid ) != 1) { - if (feof(fp)) - return -1; - - openvzError(NULL, VIR_ERR_INTERNAL_ERROR, - "%s", _("Failed to parse vzlist output")); - goto cleanup; - } - - return veid; - - cleanup: + ok = fscanf(fp, "%d\n", &veid ) == 1; fclose(fp); + if (ok && veid >= 0) + return veid; + + openvzError(NULL, VIR_ERR_INTERNAL_ERROR, + "%s", _("Failed to parse vzlist output")); return -1; } -- 1.7.0.401.g84adb