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