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@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list