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

[Xen-devel] XenStore difficulties.

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] XenStore difficulties.
From: John McCullough <jmccullo@xxxxxxxxxxx>
Date: Mon, 13 Nov 2006 21:23:52 -0800
Delivery-date: Mon, 13 Nov 2006 21:24:14 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Mail-followup-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
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

Given that I am unwatching the watches in xsblockingchannel I don't
think the memory leak would be due to me.  As far as the lost watches
are concerned, I would speculate that something is wrong with qemu's
select/callback handling, or that xenstore is racing and dropping
things.  If the memory leak has already been fixed, I apologise for the
noise.  I am moving on to unix domain sockets for now, as I have been
running into this problem for a while and I don't currently have the
patience to debug it, but I thought I should mention it so that it is on
the general radar.

Once I finish with the domain sockets I should find out whether it is
the qemu select handling.

Regards,
John McCullough

Attachment: commandee.c
Description: Text Data

Attachment: commander.py
Description: Text Data

Attachment: xsblockingchannel.py
Description: Text Data

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>