On Fri, Jan 27, 2023 at 02:37:29PM +0100, Jiri Denemark wrote:
> Theoretically, when remoteDomainMigrateFinish3* is called without a
> pointer for storing migration cookie and its length (i.e., either
> cookieout == NULL or cookieoutlen == NULL), we would leak the freshly
> created virDomain
Theoretically, when remoteDomainMigrateFinish3* is called without a
pointer for storing migration cookie and its length (i.e., either
cookieout == NULL or cookieoutlen == NULL), we would leak the freshly
created virDomain object referenced by rv.
Signed-off-by: Jiri Denemark
---
The remote call actually doesn't free the arguments array so we leak
memory in case a domain list is specified. As the remote domain list
array consists only of stolen pointers from the actual domain objects
it's sufficient just to free the array.
Valgrind message:
==1081452== 64 bytes in 1
On 05.11.2014 12:45, Peter Krempa wrote:
The remote call actually doesn't free the arguments array so we leak
memory in case a domain list is specified. As the remote domain list
array consists only of stolen pointers from the actual domain objects
it's sufficient just to free the array.
The 'elem' variable along with the domain object would be leaked when
taking the error path.
Found by coverity.
---
src/remote/remote_driver.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index
On Tue, Sep 02, 2014 at 03:18:39PM +0200, Peter Krempa wrote:
The 'elem' variable along with the domain object would be leaked when
taking the error path.
Found by coverity.
---
src/remote/remote_driver.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
ACK,
Martin
diff --git
On 09/02/14 15:27, Martin Kletzander wrote:
On Tue, Sep 02, 2014 at 03:18:39PM +0200, Peter Krempa wrote:
The 'elem' variable along with the domain object would be leaked when
taking the error path.
Found by coverity.
---
src/remote/remote_driver.c | 8 ++--
1 file changed, 6
On 07/10/2011 11:14 PM, a...@redhat.com wrote:
From: Alex Jia a...@redhat.com
Detected in valgrind run:
==9184== 1 bytes in 1 blocks are definitely lost in loss record 1 of 19
==9184==at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==9184==by 0x3073715F78: xdr_array
Detected in this valgrind run:
https://bugzilla.redhat.com/show_bug.cgi?id=690734
==13864== 10 bytes in 1 blocks are definitely lost in loss record 10 of 34
==13864==at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==13864==by 0x308587FD91: strdup (in /lib64/libc-2.12.so)
==13864==by
