WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: How to use valgrind to detect xen hypervisor's memor

To: hellokitty <zhuce5555@xxxxxxx>
Subject: Re: [Xen-devel] Re: How to use valgrind to detect xen hypervisor's memory leak
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Fri, 15 Jul 2011 10:43:58 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 15 Jul 2011 02:44:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1310721336532-4589993.post@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1310697774774-4589174.post@xxxxxxxxxxxxx> <1310714382.11556.6.camel@xxxxxxxxxxxxxxxxxxxx> <1310721336532-4589993.post@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2011-07-15 at 10:15 +0100, hellokitty wrote:
> > Please post your modified version of the patch. 
> My patch is in the attach file named  xen_patch.patch 
> http://xen.1045712.n5.nabble.com/file/n4589993/xen_patch.patch
> xen_patch.patch 
> 
> > You seem to have missed step 0) which is to regenerate configure and
> > Makefile.* using autoconf/automake as I described in a previous mail. 
> Oh , here before i run 
>                   1)     ./configure --with-xen=/usr/include/xen/     &&  
>                   2)     make && make install 
>  i had run automake/autoconf tool , and the errors still like what i got .
> So how to fix it ?

I'm not sure to be honest. It would help if you would post the actual
patch you are using (including your modifications etc). Also which
specific baseline valgrind are you using?

I'm afraid you will most likely need to roll your sleeves up and get
stuck into the build system to figure out why the @XEN_CFLAGS@ macro
isn't getting substituted.

> > Wait, are you trying to use valgrind on the hypervisor itself?
> > The Xen hypervisor is an "Operating System" and runs on bare metal --
> > you can't run it as a process under Linux and therefore you cannot run a
> > tool like valgrind on it.
> 
> > The valgrind support in my patch is useful for debugging the Xen
> > toolstack (e.g. "xl"), but not the hypervisor itself.
> 
> Oh , I know that, maybe i didn't express the right meaning . Now , i am more
> clearer . Yes , what i want to detect is the Xen toolstack's memory leak not
> the hypervisor itself . 
> 
> and so suppose that i come to the third step, is it right to use the command
> to do the detection ?
> "valgrind --tool=memcheck --leak-check=yes xm"

I think you can use any of the valgrind options in the normal way.

Personally I was using (with xl)
        --track-origins=yes --trace-children=yes --leak-check=full 
--show-reachable=yes

I've not got any experience with running valgrind on python programs but
since python is interpreted and garbage collected I expect that what you
will actually end up tracking is bugs in the python runtime and what you
will miss is any kind of leak due to something not getting garbage
collected when you might expect etc. I'm not sure what kind of tools are
available for tracking memory "leaks" of this sort in python. (In other
words I'm not sure there is much utility to running python programs
under valgrind, but I suppose you know different)

Note that xm is really just an RPC client to the xend server, so you
won't actually be checking the toolstack by running valgrind on xm, only
the client RPC implementation. To actually measure anything useful you
would need to measure xend itself (also note that xend is not generally
well supported these days and xl is generally preferred for new
development).

My patch was written to support all the hypercalls done by "xl create"
on my specific guest configuration -- you may find you need to implement
support within Valgrind for other hypercalls if you step outside this
limited usage.

> and more does someone have the valgrind tool support for hypervisor well ,
> can you send me one ?

Um, I think I explained in my previous mail why this isn't possible and
that this request doesn't make sense. (plus you stated right above that
you don't want to do this on the hypervisor!)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel