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 object
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
---
src/remote/remot
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.
Valgrin
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 blocks
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
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 a
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 fda27f7..8bc4baa
On 07/10/2011 11:14 PM, a...@redhat.com wrote:
> From: Alex Jia
>
> 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 (xdr_array.c:97)
> ==918
From: Alex Jia
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 (xdr_array.c:97)
==9184==by 0x4CF97C9: xdr_remote_domain_get_security_label_ret
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 0x3B
10 matches
Mail list logo