[libvirt] [PATCH] fix memory leak in daemonUnixSocketPaths
The @rundir is allocated in virGetUserRuntimeDirectory, may lost when virFileMakePath failed. Signed-off-by: Xi Xu <xu.xi8@zte.com.cn> --- daemon/libvirtd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index bac4bc1..d17a694 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -288,6 +288,7 @@ daemonUnixSocketPaths(struct daemonConfig *config, old_umask = umask(077); if (virFileMakePath(rundir) < 0) { umask(old_umask); + VIR_FREE(rundir); goto error; } umask(old_umask); -- 1.8.3.1
On Mon, Jun 12, 2017 at 02:02:20AM -0400, Yi Wang wrote:
The @rundir is allocated in virGetUserRuntimeDirectory, may lost when virFileMakePath failed.
ACK. I slightly reworded the commit message and pushed. Thanks, Erik
On 06/13/2017 11:02 AM, Erik Skultety wrote:
On Mon, Jun 12, 2017 at 02:02:20AM -0400, Yi Wang wrote:
The @rundir is allocated in virGetUserRuntimeDirectory, may lost when virFileMakePath failed.
ACK. I slightly reworded the commit message and pushed.
Funny, I have a similar patch on my branch: https://github.com/zippy2/libvirt/commit/3c00409576f7b6158935baba7ff8059f66a... How about instead of putting VIR_FREE() at each exit path, we have just one exit path (= use more gotos) and have VIR_FREE() just once. Michal
On Tue, Jun 13, 2017 at 01:55:24PM +0200, Michal Privoznik wrote:
On 06/13/2017 11:02 AM, Erik Skultety wrote:
On Mon, Jun 12, 2017 at 02:02:20AM -0400, Yi Wang wrote:
The @rundir is allocated in virGetUserRuntimeDirectory, may lost when virFileMakePath failed.
ACK. I slightly reworded the commit message and pushed.
Funny, I have a similar patch on my branch:
https://github.com/zippy2/libvirt/commit/3c00409576f7b6158935baba7ff8059f66a...
How about instead of putting VIR_FREE() at each exit path, we have just one exit path (= use more gotos) and have VIR_FREE() just once.
I wanted to suggest that, but I didn't apply the "generic" rule, rather I judged the function as an individual, it's not a monster function, the variable is used just in the block, so I was OK with that as it was. Of course, your approach works just as well, it's just a few more lines of code. If you feel like doing it, I have nothing against. Erik
Michal
On 06/13/2017 03:05 PM, Erik Skultety wrote:
On Tue, Jun 13, 2017 at 01:55:24PM +0200, Michal Privoznik wrote:
On 06/13/2017 11:02 AM, Erik Skultety wrote:
On Mon, Jun 12, 2017 at 02:02:20AM -0400, Yi Wang wrote:
The @rundir is allocated in virGetUserRuntimeDirectory, may lost when virFileMakePath failed.
ACK. I slightly reworded the commit message and pushed.
Funny, I have a similar patch on my branch:
https://github.com/zippy2/libvirt/commit/3c00409576f7b6158935baba7ff8059f66a...
How about instead of putting VIR_FREE() at each exit path, we have just one exit path (= use more gotos) and have VIR_FREE() just once.
I wanted to suggest that, but I didn't apply the "generic" rule, rather I judged the function as an individual, it's not a monster function, the variable is used just in the block, so I was OK with that as it was. Of course, your approach works just as well, it's just a few more lines of code. If you feel like doing it, I have nothing against.
Actually, it's less lines of code than what we currently have. I'll post the patch shortly. Michal
On Tue, Jun 13, 2017 at 03:06:14PM +0200, Michal Privoznik wrote:
On 06/13/2017 03:05 PM, Erik Skultety wrote:
On Tue, Jun 13, 2017 at 01:55:24PM +0200, Michal Privoznik wrote:
On 06/13/2017 11:02 AM, Erik Skultety wrote:
On Mon, Jun 12, 2017 at 02:02:20AM -0400, Yi Wang wrote:
The @rundir is allocated in virGetUserRuntimeDirectory, may lost when virFileMakePath failed.
ACK. I slightly reworded the commit message and pushed.
Funny, I have a similar patch on my branch:
https://github.com/zippy2/libvirt/commit/3c00409576f7b6158935baba7ff8059f66a...
How about instead of putting VIR_FREE() at each exit path, we have just one exit path (= use more gotos) and have VIR_FREE() just once.
I wanted to suggest that, but I didn't apply the "generic" rule, rather I judged the function as an individual, it's not a monster function, the variable is used just in the block, so I was OK with that as it was. Of course, your approach works just as well, it's just a few more lines of code. If you feel like doing it, I have nothing against.
Actually, it's less lines of code than what we currently have. I'll post the patch shortly.
Aha, my bad, I meant a bigger diff, bad wording, sorry, of course the resulting number of lines will be smaller. :) Erik
Michal
participants (3)
-
Erik Skultety -
Michal Privoznik -
Yi Wang