[libvirt] [Bug] [vbox-driver] attach-device

Eric Blake eblake at redhat.com
Mon Feb 20 18:02:07 UTC 2012


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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120220/5b397f5f/attachment-0001.sig>


More information about the libvir-list mailing list