[libvirt] leak? xenUnifiedOpen
==5486== 184 bytes in 1 blocks are definitely lost in loss record 5 of 18 ==5486== at 0x4C20111: calloc (vg_replace_malloc.c:397) ==5486== by 0x4E3ADFD: __virAlloc (memory.c:100) ==5486== by 0x4E4AF21: xenUnifiedOpen (xen_unified.c:264) ==5486== by 0x4E3A005: do_open (libvirt.c:777) ==5486== by 0x4009D7: main (in /home/skinkie/development/htdocs/cherokee/experiment) Maybe valgrind is over active, because I see the free code at the close connection, and my own code is closing it... Stefan
On Sun, Jul 20, 2008 at 10:49:39PM +0200, Stefan de Konink wrote:
==5486== 184 bytes in 1 blocks are definitely lost in loss record 5 of 18 ==5486== at 0x4C20111: calloc (vg_replace_malloc.c:397) ==5486== by 0x4E3ADFD: __virAlloc (memory.c:100) ==5486== by 0x4E4AF21: xenUnifiedOpen (xen_unified.c:264) ==5486== by 0x4E3A005: do_open (libvirt.c:777) ==5486== by 0x4009D7: main (in /home/skinkie/development/htdocs/cherokee/experiment)
Maybe valgrind is over active, because I see the free code at the close connection, and my own code is closing it...
I can see a possibility, for example if xenUnifiedOpen is called multipl time on the same connection but the first time it exits on line 332 of xenUnifiedOpen(). That error exit leaves the routine without deallocating the priv block and conn->privateData is not set back to NULL. Could you put a breakpoint on that line or error a message there to see if you're going though it, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jul 21, 2008 at 04:52:24AM -0400, Daniel Veillard wrote:
On Sun, Jul 20, 2008 at 10:49:39PM +0200, Stefan de Konink wrote:
==5486== 184 bytes in 1 blocks are definitely lost in loss record 5 of 18 ==5486== at 0x4C20111: calloc (vg_replace_malloc.c:397) ==5486== by 0x4E3ADFD: __virAlloc (memory.c:100) ==5486== by 0x4E4AF21: xenUnifiedOpen (xen_unified.c:264) ==5486== by 0x4E3A005: do_open (libvirt.c:777) ==5486== by 0x4009D7: main (in /home/skinkie/development/htdocs/cherokee/experiment)
Maybe valgrind is over active, because I see the free code at the close connection, and my own code is closing it...
I can see a possibility, for example if xenUnifiedOpen is called multipl time on the same connection but the first time it exits on line 332 of xenUnifiedOpen(). That error exit leaves the routine without deallocating the priv block and conn->privateData is not set back to NULL.
Yes, we definitely need to free the 'priv' data on line 332. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Jul 21, 2008 at 10:27:45AM +0100, Daniel P. Berrange wrote:
On Mon, Jul 21, 2008 at 04:52:24AM -0400, Daniel Veillard wrote:
On Sun, Jul 20, 2008 at 10:49:39PM +0200, Stefan de Konink wrote:
==5486== 184 bytes in 1 blocks are definitely lost in loss record 5 of 18 ==5486== at 0x4C20111: calloc (vg_replace_malloc.c:397) ==5486== by 0x4E3ADFD: __virAlloc (memory.c:100) ==5486== by 0x4E4AF21: xenUnifiedOpen (xen_unified.c:264) ==5486== by 0x4E3A005: do_open (libvirt.c:777) ==5486== by 0x4009D7: main (in /home/skinkie/development/htdocs/cherokee/experiment)
Maybe valgrind is over active, because I see the free code at the close connection, and my own code is closing it...
I can see a possibility, for example if xenUnifiedOpen is called multipl time on the same connection but the first time it exits on line 332 of xenUnifiedOpen(). That error exit leaves the routine without deallocating the priv block and conn->privateData is not set back to NULL.
Yes, we definitely need to free the 'priv' data on line 332.
I suggest the following Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Jul 21, 2008 at 05:36:44AM -0400, Daniel Veillard wrote:
On Mon, Jul 21, 2008 at 10:27:45AM +0100, Daniel P. Berrange wrote:
On Mon, Jul 21, 2008 at 04:52:24AM -0400, Daniel Veillard wrote:
On Sun, Jul 20, 2008 at 10:49:39PM +0200, Stefan de Konink wrote:
==5486== 184 bytes in 1 blocks are definitely lost in loss record 5 of 18 ==5486== at 0x4C20111: calloc (vg_replace_malloc.c:397) ==5486== by 0x4E3ADFD: __virAlloc (memory.c:100) ==5486== by 0x4E4AF21: xenUnifiedOpen (xen_unified.c:264) ==5486== by 0x4E3A005: do_open (libvirt.c:777) ==5486== by 0x4009D7: main (in /home/skinkie/development/htdocs/cherokee/experiment)
Maybe valgrind is over active, because I see the free code at the close connection, and my own code is closing it...
I can see a possibility, for example if xenUnifiedOpen is called multipl time on the same connection but the first time it exits on line 332 of xenUnifiedOpen(). That error exit leaves the routine without deallocating the priv block and conn->privateData is not set back to NULL.
Yes, we definitely need to free the 'priv' data on line 332.
I suggest the following
ACK.
@@ -329,7 +329,8 @@ xenUnifiedOpen (virConnectPtr conn, xmlU } #else DEBUG0("Handing off for remote driver"); - return VIR_DRV_OPEN_DECLINED; /* Let remote_driver try instead */ + ret = VIR_DRV_OPEN_DECLINED; /* Let remote_driver try instead */ + goto clean; #endif
Small whitespace bug there. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Jul 21, 2008 at 10:38:04AM +0100, Daniel P. Berrange wrote:
On Mon, Jul 21, 2008 at 05:36:44AM -0400, Daniel Veillard wrote:
I suggest the following
ACK.
@@ -329,7 +329,8 @@ xenUnifiedOpen (virConnectPtr conn, xmlU } #else DEBUG0("Handing off for remote driver"); - return VIR_DRV_OPEN_DECLINED; /* Let remote_driver try instead */ + ret = VIR_DRV_OPEN_DECLINED; /* Let remote_driver try instead */ + goto clean; #endif
Small whitespace bug there.
Seems my vim automatically starts to fill out with tabs for alignment ... Okay, cleaned up and commited Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink