[libvirt] [Bug] [vbox-driver] attach-device
Hi, using the version from git I can't attach devices to my domain (using attach-device) neither using the virsh or a language binding. In both cases it throws a OutOfMemory exception. It gets thrown in vbox_tmpl.c:5340, although I got 7gb of RAM left. Am I doing something wrong, or is this a bug ? Thanks ! -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On 02/09/2012 03:21 AM, Gravok wrote:
Hi,
using the version from git I can't attach devices to my domain (using attach-device) neither using the virsh or a language binding.
In both cases it throws a OutOfMemory exception.
It gets thrown in vbox_tmpl.c:5340, although I got 7gb of RAM left.
Line numbers without corresponding function names makes it hard to tell if I'm looking at the same place of code. Stating which commit id you actually tested makes the report a bit more reliable. But in commit 612fd157, that line of vbox_tmpl.c really is after a VIR_ALLOC; at which point I have to suspect that you are either out of memory or we have a heap corruption bug that has corrupted the malloc arena.
Am I doing something wrong, or is this a bug ?
Most likely, a bug, but to be sure, we'd need to know what XML string you are passing to attach-device, and you might also want to run things through valgrind to see if we really are smashing the heap in your particular case. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
[...]we'd need to know what XML string you are passing to attach-device
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <device> <disk device="cdrom" type="file"> <source file="/tmp/foo.iso"/> <target dev="hdc"/> <readonly/> </disk> </device> If I run it without the first line, I get an "unexptected error".
and you might also want to run things through valgrind to see if we really are smashing the heap in your particular case.
I'm new to valgrind so hopefully this output is helpfull for you: ==2735== Memcheck, a memory error detector ==2735== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2735== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2735== Command: virsh ==2735== ==2735== Conditional jump or move depends on uninitialised value(s) ==2735== at 0x5E8D27B: __GI___strcasecmp_l (strcmp.S:243) ==2735== by 0x5E2CE2C: __gconv_open (gconv_open.c:70) ==2735== by 0x5E39EB6: _nl_find_msg (dcigettext.c:990) ==2735== by 0x5E3A673: __dcigettext (dcigettext.c:654) ==2735== by 0x42FA32: main (virsh.c:19291) ==2735== ==2735== Use of uninitialised value of size 8 ==2735== at 0x5E8F3B4: __GI___strcasecmp_l (strcmp.S:2257) ==2735== by 0x5E2CE2C: __gconv_open (gconv_open.c:70) ==2735== by 0x5E39EB6: _nl_find_msg (dcigettext.c:990) ==2735== by 0x5E3A673: __dcigettext (dcigettext.c:654) ==2735== by 0x42FA32: main (virsh.c:19291) ==2735== ==2735== Use of uninitialised value of size 8 ==2735== at 0x5E8F3B8: __GI___strcasecmp_l (strcmp.S:2258) ==2735== by 0x5E2CE2C: __gconv_open (gconv_open.c:70) ==2735== by 0x5E39EB6: _nl_find_msg (dcigettext.c:990) ==2735== by 0x5E3A673: __dcigettext (dcigettext.c:654) ==2735== by 0x42FA32: main (virsh.c:19291) ==2735== [...] virsh # attach-device dos /tmp/bla.xml Fehler: Fehler beim Anhängen des Geräts von /tmp/bla.xml Fehler: zu wenig Arbeitsspeicher [...] ==2735== ==2735== HEAP SUMMARY: ==2735== in use at exit: 191,210 bytes in 1,495 blocks ==2735== total heap usage: 3,907 allocs, 2,412 frees, 1,390,037 bytes allocated ==2735== ==2735== LEAK SUMMARY: ==2735== definitely lost: 60 bytes in 1 blocks ==2735== indirectly lost: 240 bytes in 10 blocks ==2735== possibly lost: 701 bytes in 26 blocks ==2735== still reachable: 190,209 bytes in 1,458 blocks ==2735== suppressed: 0 bytes in 0 blocks [...] ==2735== ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 73 from 7) Also I used gdb to see where the virAlloc() which fails is called: Breakpoint 1, virAlloc (ptrptr=0x7fffffffd960, size=776) at util/memory.c:93 93 { (gdb) bt #0 virAlloc (ptrptr=0x7fffffffd960, size=776) at util/memory.c:93 #1 0x00007ffff7b37d73 in vboxDomainAttachDeviceImpl (dom=0x6bcc80, xml=0x6c8f50 "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<device>\n<disk device=\"cdrom\" type=\"file\">\n<source file=\"/tmp/foo.iso\"/>\n<target dev=\"hdc\"/>\n<readonly/>\n</disk>\n</device>\n", mediaChangeOnly=<optimized out>) at vbox/vbox_tmpl.c:5339 #2 0x00007ffff7a5dc10 in virDomainAttachDevice (domain=0x6bcc80, xml=0x6c8f50 "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<device>\n<disk device=\"cdrom\" type=\"file\">\n<source file=\"/tmp/foo.iso\"/>\n<target dev=\"hdc\"/>\n<readonly/>\n</disk>\n</device>\n") at libvirt.c:9172 #3 0x000000000041aea5 in cmdAttachDevice (ctl=0x7fffffffdd20, cmd=0x6c8c50) at virsh.c:13144 #4 0x00000000004118e5 in vshCommandRun (ctl=0x7fffffffdd20, cmd=0x6c8c50) at virsh.c:17710 #5 0x000000000042f9a8 in main (argc=<optimized out>, argv=<optimized out>) at virsh.c:19315 (gdb) n 101 *(void **)ptrptr = calloc(1, size); (gdb) n 103 return -1; I'm using the current version from git (5452e88). Hope the informations are useful this time. Thanks in advance ! -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On 02/15/2012 05:32 AM, Gravok wrote:
[...]we'd need to know what XML string you are passing to attach-device
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <device>
I think that's the problem. 'virsh attach-device' was designed to treat as its top-level element one of the sub-elements of a domain's <devices> element; that is, your top-level element should be <disk>, not <device>. We probably need to document that better - can you help in that effort?
<disk device="cdrom" type="file"> <source file="/tmp/foo.iso"/> <target dev="hdc"/> <readonly/> </disk> </device>
If I run it without the first line, I get an "unexptected error".
When I've used 'virsh attach-device' in the past, I never tried the <?xml> prefix; I just started out directly with the <interface> or <disk> that I was attaching. I'm not sure if the <?xml> prefix makes a difference, or even whether it should make a difference.
and you might also want to run things through valgrind to see if we really are smashing the heap in your particular case.
I'm new to valgrind so hopefully this output is helpfull for you:
==2735== Memcheck, a memory error detector ==2735== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2735== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2735== Command: virsh ==2735== ==2735== Conditional jump or move depends on uninitialised value(s) ==2735== at 0x5E8D27B: __GI___strcasecmp_l (strcmp.S:243)
==2735== Use of uninitialised value of size 8 ==2735== at 0x5E8F3B4: __GI___strcasecmp_l (strcmp.S:2257)
==2735== Use of uninitialised value of size 8 ==2735== at 0x5E8F3B8: __GI___strcasecmp_l (strcmp.S:2258)
Known valgrind weaknesses (in all three cases, glibc is doing something safe, but valgrind hasn't been taught to recognize that glibc usage yet).
==2735== LEAK SUMMARY: ==2735== definitely lost: 60 bytes in 1 blocks
So we have a leak of 60 bytes somewhere, but you trimmed enough from your reply that you didn't actually paste where the leak was occurring.
Also I used gdb to see where the virAlloc() which fails is called:
Breakpoint 1, virAlloc (ptrptr=0x7fffffffd960, size=776) at util/memory.c:93 93 { (gdb) bt #0 virAlloc (ptrptr=0x7fffffffd960, size=776) at util/memory.c:93
size 776 isn't unreasonable, so I'm not sure why things are failing.
#1 0x00007ffff7b37d73 in vboxDomainAttachDeviceImpl (dom=0x6bcc80, xml=0x6c8f50 "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<device>\n<disk device=\"cdrom\" type=\"file\">\n<source file=\"/tmp/foo.iso\"/>\n<target dev=\"hdc\"/>\n<readonly/>\n</disk>\n</device>\n", mediaChangeOnly=<optimized out>) at vbox/vbox_tmpl.c:5339 #2 0x00007ffff7a5dc10 in virDomainAttachDevice (domain=0x6bcc80, xml=0x6c8f50 "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<device>\n<disk device=\"cdrom\" type=\"file\">\n<source file=\"/tmp/foo.iso\"/>\n<target dev=\"hdc\"/>\n<readonly/>\n</disk>\n</device>\n") at libvirt.c:9172 #3 0x000000000041aea5 in cmdAttachDevice (ctl=0x7fffffffdd20, cmd=0x6c8c50) at virsh.c:13144 #4 0x00000000004118e5 in vshCommandRun (ctl=0x7fffffffdd20, cmd=0x6c8c50) at virsh.c:17710 #5 0x000000000042f9a8 in main (argc=<optimized out>, argv=<optimized out>) at virsh.c:19315 (gdb) n 101 *(void **)ptrptr = calloc(1, size); (gdb) n 103 return -1;
I'm using the current version from git (5452e88).
Hope the informations are useful this time.
Yes, that extra information certainly helps, although I still haven't reproduced the problem to get to a root cause. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (2)
-
Eric Blake -
Gravok