On 05/23/2018 02:40 PM, Roland Schulz wrote:
> Signed-off-by: Roland Schulz
> ---
> tools/virsh-completer.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/virsh-completer.c b/tools/virsh-completer.c
> index 1435d1d4c..c72f3bcad 100644
> --- a/tools/virsh-c
Signed-off-by: Roland Schulz
---
tools/virsh-completer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/virsh-completer.c b/tools/virsh-completer.c
index 1435d1d4c..c72f3bcad 100644
--- a/tools/virsh-completer.c
+++ b/tools/virsh-completer.c
@@ -576,6 +576,7 @@
On Mon, Jun 12, 2017 at 02:05:55AM -0400, Yi Wang wrote:
> The @tlsalias allocated in qemuAliasTLSObjFromSrcAlias may lost
> when append string to json.
>
> Signed-off-by: Xi Xu
> ---
> src/qemu/qemu_monitor_json.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/qemu/qemu_monitor_js
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:
> >
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
wh
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 slight
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 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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.co
The @tlsalias allocated in qemuAliasTLSObjFromSrcAlias may lost
when append string to json.
Signed-off-by: Xi Xu
---
src/qemu/qemu_monitor_json.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index f208dd0..773de0f 100644
--- a/s
The @rundir is allocated in virGetUserRuntimeDirectory, may lost
when virFileMakePath failed.
Signed-off-by: Xi Xu
---
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/li
On Fri, May 26, 2017 at 21:10:50 -0400, Yi Wang wrote:
> From: Xi Xu
>
> The @rundir is allocated in virGetUserRuntimeDirectory, may lost
> when virFileMakePath failed.
>
> The tlsalias allocated in qemuAliasTLSObjFromSrcAlias may lost
> when append string to json.
Those are two separate change
From: Xi Xu
The @rundir is allocated in virGetUserRuntimeDirectory, may lost
when virFileMakePath failed.
The tlsalias allocated in qemuAliasTLSObjFromSrcAlias may lost
when append string to json.
---
daemon/libvirtd.c| 1 +
src/qemu/qemu_monitor_json.c | 2 ++
2 files changed, 3 in
On Fri, Apr 24, 2015 at 13:34:25 +0200, Michal Privoznik wrote:
> On 24.04.2015 12:03, Jiri Denemark wrote:
...
> > - error:
> > + cleanup:
> > if (lockfd != -1) {
> > unlink(lockpath);
> > VIR_FORCE_CLOSE(lockfd);
> > }
> > VIR_FREE(lockpath);
> > VIR_FREE(run
On 24.04.2015 12:03, Jiri Denemark wrote:
> ==26726==by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80)
> ==26726==by 0x5673605: UnknownInlinedFun (stdio2.h:210)
> ==26726==by 0x5673605: virVasprintfInternal (virstring.c:476)
> ==26726==by 0x56736EE: virAsprintfInternal (virstring.c
On Fri, Apr 24, 2015 at 12:03:37 +0200, Jiri Denemark wrote:
> ==26726==by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80)
> ==26726==by 0x5673605: UnknownInlinedFun (stdio2.h:210)
> ==26726==by 0x5673605: virVasprintfInternal (virstring.c:476)
> ==26726==by 0x56736EE: virAsprintfIn
==26726==by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80)
==26726==by 0x5673605: UnknownInlinedFun (stdio2.h:210)
==26726==by 0x5673605: virVasprintfInternal (virstring.c:476)
==26726==by 0x56736EE: virAsprintfInternal (virstring.c:497)
==26726==by 0x5680C37: virGetUserRuntime
On 10/30/2014 02:27 PM, Peter Krempa wrote:
On 10/30/14 03:35, Luyao Huang wrote:
After use cidr_format in function virAsprintf and vshPrintExtra, need free
cidr_format.
Fix the following memory leak from valgrind, like:
18 bytes in 1 blocks are definitely lost in loss record 41 of 192
On 10/30/14 03:35, Luyao Huang wrote:
> After use cidr_format in function virAsprintf and vshPrintExtra, need free
> cidr_format.
>
> Fix the following memory leak from valgrind, like:
> 18 bytes in 1 blocks are definitely lost in loss record 41 of 192
> at 0x4C29BBD: malloc (in
> /usr/lib64
In subject: I've added "virsh:" designator to make clear which part of
the code the patch touches.
On 10/30/14 03:35, Luyao Huang wrote:
> After use cidr_format in function virAsprintf and vshPrintExtra, need free
> cidr_format.
And clarified this sentence a bit.
>
> Fix the following memory le
After use cidr_format in function virAsprintf and vshPrintExtra, need free
cidr_format.
Fix the following memory leak from valgrind, like:
18 bytes in 1 blocks are definitely lost in loss record 41 of 192
at 0x4C29BBD: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by
On 04/18/2014 01:15 AM, Nehal J Wani wrote:
> While running virstoragetest, valgrind pointed out the following
> memory leak:
>
> ==8142== 2 bytes in 1 blocks are definitely lost in loss record 1 of 92
> ==8142==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
> ==8142==by 0x4E7B53E: mdir_na
While running virstoragetest, valgrind pointed out the following
memory leak:
==8142== 2 bytes in 1 blocks are definitely lost in loss record 1 of 92
==8142==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==8142==by 0x4E7B53E: mdir_name (dirname-lgpl.c:78)
==8142==by 0x4CBE2B0: virStor
On 04/03/2014 08:13 PM, Nehal J Wani wrote:
> Fixes leak introduced by e562e82f
>
> ==4937== 64 bytes in 1 blocks are definitely lost in loss record 270 of 405
> ==4937==at 0x4A06BE0: realloc (vg_replace_malloc.c:662)
> ==4937==by 0x6FA41C4: __vasprintf_chk (vasprintf_chk.c:90)
> ==4937==
Fixes leak introduced by e562e82f
==4937== 64 bytes in 1 blocks are definitely lost in loss record 270 of 405
==4937==at 0x4A06BE0: realloc (vg_replace_malloc.c:662)
==4937==by 0x6FA41C4: __vasprintf_chk (vasprintf_chk.c:90)
==4937==by 0x50C8D29: virVasprintfInternal (stdio2.h:199)
==4
On 03/30/2014 03:35 PM, Nehal J Wani wrote:
> While running virdbustest, it was found that valgrind pointed out
> the following memory leaks:
>
> ==9996== 17 (8 direct, 9 indirect) bytes in 1 blocks are definitely lost in
> loss record 9 of 36
> ==9996==at 0x4A069EE: malloc (vg_replace_malloc
While running virdbustest, it was found that valgrind pointed out
the following memory leaks:
==9996== 17 (8 direct, 9 indirect) bytes in 1 blocks are definitely lost in
loss record 9 of 36
==9996==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==9996==by 0x4A06B62: realloc (vg_replace_ma
On 03/26/2014 11:37 PM, Nehal J Wani wrote:
> While running qemucaps2xmltest, it was found that valgrind pointed out
> the following memory leaks:
>
> ==27045== 160 (112 direct, 48 indirect) bytes in 1 blocks are definitely lost
> in loss record 51 of 65
> ==27045==at 0x4A0577B: calloc (vg_re
While running qemucaps2xmltest, it was found that valgrind pointed out
the following memory leaks:
==27045== 160 (112 direct, 48 indirect) bytes in 1 blocks are definitely lost
in loss record 51 of 65
==27045==at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==27045==by 0x4C6BACD: virAllocV
On Thu, Mar 27, 2014 at 12:00:49AM +0530, Nehal J Wani wrote:
> While running qemucaps2xmltest, it was found that valgrind pointed out
> the following memory leaks:
>
> ==29896== 0 bytes in 1 blocks are definitely lost in loss record 1 of 65
> ==29896==at 0x4A0577B: calloc (vg_replace_malloc.c
While running qemucaps2xmltest, it was found that valgrind pointed out
the following memory leaks:
==29896== 0 bytes in 1 blocks are definitely lost in loss record 1 of 65
==29896==at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==29896==by 0x4C6B45E: virAllocN (viralloc.c:191)
==29896==
On Tue, Mar 18, 2014 at 01:02:24PM +0530, Nehal J Wani wrote:
> While running qemuxml2xmltest, it was found that valgrind pointed out
> the following memory leak:
>
> ==21905== 26 bytes in 1 blocks are definitely lost in loss record 23 of 69
> ==21905==at 0x4A069EE: malloc (vg_replace_malloc.c
While running qemuxml2xmltest, it was found that valgrind pointed out
the following memory leak:
==21905== 26 bytes in 1 blocks are definitely lost in loss record 23 of 69
==21905==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==21905==by 0x3E782A754D: xmlStrndup (in /usr/lib64/libxml2.so
On 03/04/14 10:44, Ján Tomko wrote:
> [cc-ing Peter as he invented the function]
>
> On 03/03/2014 09:04 PM, Nehal J Wani wrote:
---
src/conf/snapshot_conf.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/conf/snapshot_conf.c b/src/conf/snapsh
[cc-ing Peter as he invented the function]
On 03/03/2014 09:04 PM, Nehal J Wani wrote:
>>> ---
>>> src/conf/snapshot_conf.c |1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/conf/snapshot_conf.c b/src/conf/snapshot_conf.c
>>> index 12b0930..475525f 100644
>>>
>> ---
>> src/conf/snapshot_conf.c |1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/conf/snapshot_conf.c b/src/conf/snapshot_conf.c
>> index 12b0930..475525f 100644
>> --- a/src/conf/snapshot_conf.c
>> +++ b/src/conf/snapshot_conf.c
>> @@ -82,6 +82,7 @@ virDomai
On 02/22/2014 08:37 PM, Nehal J Wani wrote:
> While running domainsnapshotxml2xmltest, it was found that valgrind pointed
> out
> the following memory leaks:
>
> ==32176== 42 (32 direct, 10 indirect) bytes in 1 blocks are definitely lost
> in loss record 42 of 66
> ==32176==at 0x4A069EE: mal
On 02/22/2014 09:00 PM, Nehal J Wani wrote:
> While running virscsitest, it was found that valgrind pointed out the
> following
> memory leak:
>
> ==320== 5 bytes in 1 blocks are definitely lost in loss record 4 of 37
> ==320==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
> ==320==by 0x3
On 02/24/2014 08:04 AM, shyu wrote:
> | And judging by the code, this is not upstream at all, right? I guess
> | this is not applicable upstream for half a year already, at least.
> | Please submit patches that apply on top of current master when cloning
> | from git://libvirt.org/libvirt.git .
>
- Original Message -
| From: "Martin Kletzander"
| To: "shyu"
| Cc: libvir-list@redhat.com
| Sent: Monday, February 24, 2014 4:48:01 PM
| Subject: Re: [libvirt] [PATCH] Fix memory leak when lookup pool list with
invalid type option
|
| On Mon, Feb 24, 2014 at 02
On Mon, Feb 24, 2014 at 02:12:34PM +0800, shyu wrote:
> There will be memory leak when lookup pool list with invalid type option
> https://bugzilla.redhat.com/show_bug.cgi?id=1069068
>
> ==23060== Memcheck, a memory error detector
> ==23060== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward
There will be memory leak when lookup pool list with invalid type option
https://bugzilla.redhat.com/show_bug.cgi?id=1069068
==23060== Memcheck, a memory error detector
==23060== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==23060== Using Valgrind-3.8.1 and LibVEX; rerun with -
While running virscsitest, it was found that valgrind pointed out the following
memory leak:
==320== 5 bytes in 1 blocks are definitely lost in loss record 4 of 37
==320==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==320==by 0x3E6CE81171: strdup (strdup.c:43)
==320==by 0x4CB28DF: vi
While running domainsnapshotxml2xmltest, it was found that valgrind pointed out
the following memory leaks:
==32176== 42 (32 direct, 10 indirect) bytes in 1 blocks are definitely lost in
loss record 42 of 66
==32176==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==32176==by 0x4A06B62: re
On 01/14/2014 02:10 PM, Nehal J Wani wrote:
> While running objecteventtest, it was found that valgrind pointed out the
> following memory leak:
>
> ==13025== 538 (56 direct, 482 indirect) bytes in 1 blocks are definitely lost
> in loss record 216 of 226
> ==13025==at 0x4A06B6F: calloc (vg_re
While running objecteventtest, it was found that valgrind pointed out the
following memory leak:
==13025== 538 (56 direct, 482 indirect) bytes in 1 blocks are definitely lost
in loss record 216 of 226
==13025==at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==13025==by 0x4C65D8D: virAl
On 13.12.2013 13:38, Nehal J Wani wrote:
> While running objecteventtest, it was found that valgrind pointed out the
> following memory leak:
>
> ==13464== 5 bytes in 1 blocks are definitely lost in loss record 7 of 134
> ==13464==at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==13464==b
While running objecteventtest, it was found that valgrind pointed out the
following memory leak:
==13464== 5 bytes in 1 blocks are definitely lost in loss record 7 of 134
==13464==at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==13464==by 0x341F485E21: strdup (strdup.c:42)
==13464==by
On Thu, Dec 5, 2013 at 2:17 AM, Eric Blake wrote:
> On 12/04/2013 01:23 PM, Nehal J Wani wrote:
>> This patch fixes memory leaks reported by valgrind on running
>> qemuxml2argvtest
>>
>> Most of them are of the form:
>>
>> ==24777== 15 bytes in 1 blocks are definitely lost in loss record 39 of 12
On 12/04/2013 01:23 PM, Nehal J Wani wrote:
> This patch fixes memory leaks reported by valgrind on running qemuxml2argvtest
>
> Most of them are of the form:
>
> ==24777== 15 bytes in 1 blocks are definitely lost in loss record 39 of 129
> ==24777==at 0x4A0887C: malloc (vg_replace_malloc.c:2
This patch fixes memory leaks reported by valgrind on running qemuxml2argvtest
Most of them are of the form:
==24777== 15 bytes in 1 blocks are definitely lost in loss record 39 of 129
==24777==at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==24777==by 0x341F485E21: strdup (strdup.c:42)
=
On Fri, Nov 29, 2013 at 10:31:05PM +0530, Nehal J Wani wrote:
> This patch fixes the memory leaks found while running qemuxml2argvtest
>
> ==8260== 3 bytes in 1 blocks are definitely lost in loss record 1 of 129
> ==8260==at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==8260==by 0x341F48
This patch fixes the memory leaks found while running qemuxml2argvtest
==8260== 3 bytes in 1 blocks are definitely lost in loss record 1 of 129
==8260==at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==8260==by 0x341F485E21: strdup (strdup.c:42)
==8260==by 0x4CADCFF: virStrdup (virstrin
On Fri, Nov 29, 2013 at 8:54 PM, Daniel P. Berrange wrote:
> On Fri, Nov 29, 2013 at 08:40:31PM +0530, Nehal J Wani wrote:
>> >
>> > I think it is preferrable to use virNWFilterEntryFree() here.
>> >
>> >> if (entry->rule || entry->include) {
>> >
>> > Just following this line there i
On Fri, Nov 29, 2013 at 08:40:31PM +0530, Nehal J Wani wrote:
> >
> > I think it is preferrable to use virNWFilterEntryFree() here.
> >
> >> if (entry->rule || entry->include) {
> >
> > Just following this line there is another call to VIR_FREE(entry)
> > which leaks entry->rule and en
>
> I think it is preferrable to use virNWFilterEntryFree() here.
>
>> if (entry->rule || entry->include) {
>
> Just following this line there is another call to VIR_FREE(entry)
> which leaks entry->rule and entry->include. This should be made
> to call virNWFilterEntryFree too
>
>
Wo
On Fri, Nov 29, 2013 at 08:31:52PM +0530, Nehal J Wani wrote:
> While running nwfilterxml2xmltest, it was found that valgrind pointed out the
> following error...
>
> ==7466== 16 bytes in 1 blocks are definitely lost in loss record 26 of 90
> ==7466==at 0x4A06B6F: calloc (vg_replace_malloc.c:5
While running nwfilterxml2xmltest, it was found that valgrind pointed out the
following error...
==7466== 16 bytes in 1 blocks are definitely lost in loss record 26 of 90
==7466==at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==7466==by 0x4C651AD: virAlloc (viralloc.c:142)
==7466==
On 08/31/2013 09:25 AM, hw bi wrote:
>>
>> I am very glad to see your reply so fast. You can use 'Hongwei Bi' as my
>> name. If I need to
>>
>> report the bug again, please let me know. Thanks.
Thanks, your patch is now pushed.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtua
>
> I am very glad to see your reply so fast. You can use 'Hongwei Bi' as my
> name. If I need to
>
> report the bug again, please let me know. Thanks.
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 08/30/2013 09:39 PM, hwbi wrote:
> When virBufferError is ok in cmdAttachDisk,the latter
> should 'goto cleanup',instead of returning a false to
space after ',' in English (twice)
> prevent memory leaking.
> ---
> tools/virsh-domain.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions
When virBufferError is ok in cmdAttachDisk,the latter
should 'goto cleanup',instead of returning a false to
prevent memory leaking.
---
tools/virsh-domain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 3fd57fd..568d61d
On 18.02.2013 12:01, Sergey Fionov wrote:
> Commit 18937c3ae0990b4417a43aa07a2c35aaf8cb6ec2 introduced the
> memory leak when client->msg.fds is moved to thecall->msg
> and then never freed.
> ---
> Hello,
> Please ignore previous patch with incorrent formatting.
>
> src/rpc/virnetclient.c |1
Commit 18937c3ae0990b4417a43aa07a2c35aaf8cb6ec2 introduced the
memory leak when client->msg.fds is moved to thecall->msg
and then never freed.
---
Hello,
Please ignore previous patch with incorrent formatting.
src/rpc/virnetclient.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/rpc/v
Commit 18937c3ae0990b4417a43aa07a2c35aaf8cb6ec2 introduced the
memory leak when client->msg.fds is copied to thecall->msg
and then never freed.
---
src/rpc/virnetclient.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c
index 4efa578..bfa1624
Daniel P. Berrange wrote:
> On Tue, Dec 04, 2012 at 10:42:43AM -0700, Jim Fehlig wrote:
>
>> 501bfad1 missed freeing priv->saveDir when opening the Xen unified
>> driver failed.
>> ---
>> src/xen/xen_driver.c |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/src/xen/xen_driver.c b/
On Tue, Dec 04, 2012 at 10:42:43AM -0700, Jim Fehlig wrote:
> 501bfad1 missed freeing priv->saveDir when opening the Xen unified
> driver failed.
> ---
> src/xen/xen_driver.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
> index 3786176..d
501bfad1 missed freeing priv->saveDir when opening the Xen unified
driver failed.
---
src/xen/xen_driver.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
index 3786176..d2de141 100644
--- a/src/xen/xen_driver.c
+++ b/src/xen/xen_driver.c
@@ -432,
On 12/04/12 14:16, Daniel P. Berrange wrote:
From: "Daniel P. Berrange"
The qemuCapsInitQMP method never frees the QEMU 'package'
version string.
---
src/qemu/qemu_capabilities.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
ACK
Peter
--
libvir-list mailing list
libvir-list@re
From: "Daniel P. Berrange"
The qemuCapsInitQMP method never frees the QEMU 'package'
version string.
---
src/qemu/qemu_capabilities.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 6e34cdf..a0ed4f1 100644
--
On Fri, Sep 14, 2012 at 03:58:31PM +0800, Daniel Veillard wrote:
> On Fri, Sep 14, 2012 at 03:34:29PM +0800, Hu Tao wrote:
> > On Fri, Sep 14, 2012 at 03:10:13PM +0800, Daniel Veillard wrote:
> > > On Fri, Sep 14, 2012 at 02:24:15PM +0800, Hu Tao wrote:
> > > > memset before virResetError will caus
On Fri, Sep 14, 2012 at 02:24:15PM +0800, Hu Tao wrote:
> memset before virResetError will cause memory leak.
>
> virResetError and virCopyError, which calls virResetError, will do
> memset properly, so we don't have to worry about it here.
>
> ---
> src/util/virterror.c |2 --
> 1 file chan
On Fri, Sep 14, 2012 at 03:34:29PM +0800, Hu Tao wrote:
> On Fri, Sep 14, 2012 at 03:10:13PM +0800, Daniel Veillard wrote:
> > On Fri, Sep 14, 2012 at 02:24:15PM +0800, Hu Tao wrote:
> > > memset before virResetError will cause memory leak.
> > >
> > > virResetError and virCopyError, which calls v
On Fri, Sep 14, 2012 at 03:10:13PM +0800, Daniel Veillard wrote:
> On Fri, Sep 14, 2012 at 02:24:15PM +0800, Hu Tao wrote:
> > memset before virResetError will cause memory leak.
> >
> > virResetError and virCopyError, which calls virResetError, will do
> > memset properly, so we don't have to wor
On Fri, Sep 14, 2012 at 02:24:15PM +0800, Hu Tao wrote:
> memset before virResetError will cause memory leak.
>
> virResetError and virCopyError, which calls virResetError, will do
> memset properly, so we don't have to worry about it here.
Disagree, it's a public API, we can't justify behaviou
memset before virResetError will cause memory leak.
virResetError and virCopyError, which calls virResetError, will do
memset properly, so we don't have to worry about it here.
---
src/util/virterror.c |2 --
1 file changed, 2 deletions(-)
diff --git a/src/util/virterror.c b/src/util/virter
On 05/29/2012 12:04 AM, Osier Yang wrote:
On 2012年05月29日 06:18, Stefan Berger wrote:
Fix the following memory leak:
==3240== 23 bytes in 1 blocks are definitely lost in loss record 242
of 744
==3240== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==3240== by 0x8077537: __vasprintf_chk (vaspr
On 2012年05月29日 06:18, Stefan Berger wrote:
Fix the following memory leak:
==3240== 23 bytes in 1 blocks are definitely lost in loss record 242 of 744
==3240== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==3240== by 0x8077537: __vasprintf_chk (vasprintf_chk.c:82)
==3240== by 0x509C677: virVasp
Fix the following memory leak:
==3240== 23 bytes in 1 blocks are definitely lost in loss record 242 of 744
==3240==at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==3240==by 0x8077537: __vasprintf_chk (vasprintf_chk.c:82)
==3240==by 0x509C677: virVasprintf (stdio2.h:199)
==3240==by
On 12/09/2011 10:56 AM, Eric Blake wrote:
On 12/09/2011 07:51 AM, Stefan Berger wrote:
Fix memory leak:
==27534== 24 bytes in 1 blocks are definitely lost in loss record 207 of
530
==27534==at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==27534==by 0x38EC26EC37: vasprintf (in /lib64/lib
On 12/09/2011 07:51 AM, Stefan Berger wrote:
> Fix memory leak:
>
> ==27534== 24 bytes in 1 blocks are definitely lost in loss record 207 of
> 530
> ==27534==at 0x4A05E46: malloc (vg_replace_malloc.c:195)
> ==27534==by 0x38EC26EC37: vasprintf (in /lib64/libc-2.13.so)
> ==27534==by 0x4E
Fix memory leak:
==27534== 24 bytes in 1 blocks are definitely lost in loss record 207 of 530
==27534==at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==27534==by 0x38EC26EC37: vasprintf (in /lib64/libc-2.13.so)
==27534==by 0x4E998E6: virVasprintf (util.c:1677)
==27534==by 0x4E999F
On 08/31/2011 09:55 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange"
When dispatching domain events we will create an XDR struct
containing the event info. Some of this data may be allocated
on the heap and so must be freed. The graphics event dispatcher
had a broken attempt to free one
On 08/31/2011 09:55 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange"
* src/conf/domain_conf.c: Free the 'relabel' attribute
---
src/conf/domain_conf.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
ACK.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtu
From: "Daniel P. Berrange"
When dispatching domain events we will create an XDR struct
containing the event info. Some of this data may be allocated
on the heap and so must be freed. The graphics event dispatcher
had a broken attempt to free one field, but missed others. All
the events have a dom
From: "Daniel P. Berrange"
* src/conf/domain_conf.c: Free the 'relabel' attribute
---
src/conf/domain_conf.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 44212cf..00212db 100644
--- a/src/conf/domain_conf.c
+++ b/
On 08/09/2011 07:47 AM, Philipp Hahn wrote:
If a snapshot with the name already exists, virDomainSnapshotAssignDef()
just returns NULL, in which case the snapshot definition is leaked.
Currently this leak is not a big problem, since qemuDomainSnapshotLoad()
is only called once during initial star
If a snapshot with the name already exists, virDomainSnapshotAssignDef()
just returns NULL, in which case the snapshot definition is leaked.
Currently this leak is not a big problem, since qemuDomainSnapshotLoad()
is only called once during initial startup of libvirtd.
Signed-off-by: Philipp Hahn
At 06/28/2011 06:38 PM, Michal Privoznik Write:
> On 28.06.2011 05:41, Wen Congyang wrote:
>> virDomainVcpuPinDefFree() does not free def->cputune.vcpupin if nvcpupin
>> is 0, and does not set def->cputune.vcpupin to NULL.
>>
>> If we set nvcpupin to 0 but do not free vcpupin, vcpupin will not be f
On 28.06.2011 05:41, Wen Congyang wrote:
> virDomainVcpuPinDefFree() does not free def->cputune.vcpupin if nvcpupin
> is 0, and does not set def->cputune.vcpupin to NULL.
>
> If we set nvcpupin to 0 but do not free vcpupin, vcpupin will not be freed
> when vm->def is freed.
>
> Use VIR_FREE() ins
virDomainVcpuPinDefFree() does not free def->cputune.vcpupin if nvcpupin
is 0, and does not set def->cputune.vcpupin to NULL.
If we set nvcpupin to 0 but do not free vcpupin, vcpupin will not be freed
when vm->def is freed.
Use VIR_FREE() instead of virDomainVcpuPinDefFree() to free the memory
an
2011/4/30 Eric Blake :
> On 04/30/2011 05:11 AM, Matthias Bolte wrote:
>> Commit e0d014f2379dd made binary potentially allocated on the heap.
>> It was freed in the parent in the error path, but not in the success path
>> that doesn't goto the cleanup label.
>>
>> Found by 'make -C tests valgrind'.
On 04/30/2011 05:11 AM, Matthias Bolte wrote:
> Commit e0d014f2379dd made binary potentially allocated on the heap.
> It was freed in the parent in the error path, but not in the success path
> that doesn't goto the cleanup label.
>
> Found by 'make -C tests valgrind'.
> ---
> src/util/util.c |
Commit e0d014f2379dd made binary potentially allocated on the heap.
It was freed in the parent in the error path, but not in the success path
that doesn't goto the cleanup label.
Found by 'make -C tests valgrind'.
---
src/util/util.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
于 2011-4-2 0:26, Eric Blake 写道:
On 03/30/2011 01:46 AM, Wen Congyang wrote:
If strdup("x509dname") or strdup("saslUsername") success, but
strdup(x509dname) or strdup(saslUsername) failed, subject->nidentity
is not the num elements of subject->identities, and we will leak some
memory.
---
src/
On 03/30/2011 01:46 AM, Wen Congyang wrote:
> If strdup("x509dname") or strdup("saslUsername") success, but
> strdup(x509dname) or strdup(saslUsername) failed, subject->nidentity
> is not the num elements of subject->identities, and we will leak some
> memory.
>
> ---
> src/qemu/qemu_process.c |
If strdup("x509dname") or strdup("saslUsername") success, but
strdup(x509dname) or strdup(saslUsername) failed, subject->nidentity
is not the num elements of subject->identities, and we will leak some
memory.
---
src/qemu/qemu_process.c | 12 ++--
1 files changed, 6 insertions(+), 6 del
On Wed, Dec 22, 2010 at 08:48:37AM -0700, Eric Blake wrote:
> On 12/22/2010 12:12 AM, Hu Tao wrote:
> > ---
> > tools/virsh.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/tools/virsh.c b/tools/virsh.c
> > index 4e37f2d..8c123bb 100644
> > --- a/tools/virs
On 12/22/2010 12:12 AM, Hu Tao wrote:
> ---
> tools/virsh.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/tools/virsh.c b/tools/virsh.c
> index 4e37f2d..8c123bb 100644
> --- a/tools/virsh.c
> +++ b/tools/virsh.c
> @@ -10935,8 +10935,10 @@ vshCommandParse(vshCont
---
tools/virsh.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tools/virsh.c b/tools/virsh.c
index 4e37f2d..8c123bb 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -10935,8 +10935,10 @@ vshCommandParse(vshControl *ctl, vshCommandParser
*parser)
if (
On 12/08/2010 05:33 PM, Hu Tao wrote:
>> From 9ce936ee395e967551e36598ff0650315ac7686e Mon Sep 17 00:00:00 2001
>> From: Eric Blake
>> Date: Wed, 8 Dec 2010 08:03:29 -0700
>> Subject: [PATCH] command: avoid memory leak
>>
>> * src/util/command.c (virCommandRun): Fix yesterday's regression
>> on lo
1 - 100 of 113 matches
Mail list logo
