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] XenStore difficulties.

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] XenStore difficulties.
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Tue, 14 Nov 2006 10:42:16 +0000
Delivery-date: Tue, 14 Nov 2006 02:42:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061114052351.GA30871@xxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061114052351.GA30871@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Mon, Nov 13, 2006 at 09:23:52PM -0800, John McCullough wrote:

> Hello,
> 
> I am working on forking hvm domains and I have been using xenstore to
> send commands to qemu.  I have noticed that occasionally qemu's watch is
> not read.  I am using the qemu fd handler methods.  I have been trying
> to duplicate the missed read outside of qemu and the rest of xend, but I
> haven't been able to.  However, I think I may have discovered a memory
> leak in lowlevel/xs/xs.c.
> 
> I am attaching:
>    - commandee.c : consumer of "commands"
>    - commander.py : issuer of commands
>    - xsblockingchannel.py : com channel for the commander
> 
> I am working against a changset from midsummer (11536:041be3f6b38e)
> since I'm trying to iron out some of my bugs before moving forward in
> the revisions.
> 
> % gcc -o commandee commandee.c /usr/lib/libxenstore.a -lpthread
> % sudo ./commandee > /dev/null 
> % time sudo python commander.py > /dev/null #(in separate terminal)
> Traceback (most recent call last):
>   File "commander.py", line 9, in ?
>       xsbc = xsblockingchannel.xsblockingchannel("test")
>   File "/net/xen/xsstress/xsblockingchannel.py", line 19, in __init__
>         self.xs.watch(self.path, self)
>         xen.lowlevel.xs.Error: (12, 'Cannot allocate memory')
>         Exception xen.lowlevel.xs.Error: (2, 'No such file or
>         directory') in <bound method xsblockingchannel.__del__ of
>         <xsblockingchannel.xsblockingchannel instance at 0xb7ce448c>> ignored
> 
> 1.02s user 5.00s system 8% cpu 1:08.61 total

I can't remember the details, but I have vague recollection of a
Xenstore-related problem where the error was ENOMEM, but that error was
misleading.

One thing you can try is to run xenstore in trace mode: export
XENSTORED_TRACE=1 before running xend, which will add "-T
/var/log/xen/xenstored-trace.log" to the xenstore command line.  This will
give you a log of every operation on the store, which will tell us whether the
error code is coming from xenstore.

Regarding the missing read -- that's probably because you are not handling
EAGAIN when doing xs_transaction_end.  You need to retry if xs_transaction_end
fails with errno = EAGAIN, being careful not to allocate memory each retry.
See xenstore_client.c for example.

Ewan.

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

<Prev in Thread] Current Thread [Next in Thread>