Re: [libvirt] [Bug] [vbox-driver] attach-device
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)