This patch adds a test that attempts to create and destroy a domain 1025 times. Currently, this causes xm to crash after the 1014th cycle with the following stack trace:> Traceback (most recent call last): > File "/usr/sbin/xm", line 8, in ? > from xen.xm import main > File "/usr/lib/python/xen/xm/main.py", line 34, in ? > import xen.xend.XendProtocol > File "/usr/lib/python/xen/xend/XendProtocol.py", line 20, in ? > import httplib > File "/usr/lib/python2.4/httplib.py", line 70, in ? > import mimetools > File "/usr/lib/python2.4/mimetools.py", line 6, in ? > import tempfile > File "/usr/lib/python2.4/tempfile.py", line 33, in ? > from random import Random as _Random > File "/usr/lib/python2.4/random.py", line 44, in ? > from math import log as _log, exp as _exp, pi as _pi, e as _e > ImportError: /usr/lib/python2.4/lib-dynload/mathmodule.so: cannot open > shared object file: Too many open filesSince this test takes a long time to run, I have not enabled it by default, but it should be included in the tree to make bug #533 easily reproducible. Perhaps xm-test should have a configure option that enables long, exhaustive tests? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Feb 14, 2006 at 07:34:24AM -0800, Dan Smith wrote:> This patch adds a test that attempts to create and destroy a domain > 1025 times. Currently, this causes xm to crash after the 1014th cycle > with the following stack trace:The test is bogus and so if the bug. seem you don''t close the console fd by calling closeConsole at each loop.> > shared object file: Too many open filesthat it is basic ulimit behavior (usually 1024 is default configuration)> +# Copyright (C) International Business Machines Corp., 2005 > +# Author: Dan Smith <danms@us.ibm.com> > + > +from XmTestLib import * > + > +COUNT=1025 > + > +for i in range(0,COUNT): > + print "Creating %i of %i..." % (i, COUNT) > + try: > + dom = XmTestDomain(name="massive-%i" % i) > + dom.start() > + console = XmConsole(dom.getName()) > + except DomainError, e1: > + FAIL("Failed to start domain %i" % i) > + except ConsoleError, e2: > + FAIL("Failed to attach console to domain %i" % i)try to add here: + console.closeConsole()> + dom.destroy()and report back if it doesn''t fix the problem. [resent: forgot to CC xen-devel] -- Vincent Hanquez _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Feb 14, 2006 at 07:34:24AM -0800, Dan Smith wrote:> This patch adds a test that attempts to create and destroy a domain > 1025 times. Currently, this causes xm to crash after the 1014th cycle > with the following stack trace: > > > shared object file: Too many open filesThanks Dan. I''ll apply your patch soon. Meanwhile, could you run this test and then send the output of lsof when you''re a long way in (but before it crashes). It should be pretty easy to figure out where you''re leaking that file descriptor from that.> Since this test takes a long time to run, I have not enabled it by > default, but it should be included in the tree to make bug #533 easily > reproducible. > > Perhaps xm-test should have a configure option that enables long, > exhaustive tests?I thought we already had two speeds of xm-test. Do you mean add a third? If so, that''s fine, and a patch would be welcome! Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
VH> The test is bogus and so if the bug. seem you don''t close the VH> console fd by calling closeConsole at each loop. You''re right. I think what is happening is that the test exhausts all the fd''s and then exec''s xm with none free. I was trying to replicate a situation reported on xen-users, so when I hit this, I filed the bug and sent the test. Turns out, I wasn''t even replicating the right situation anyway. I''ll write a test for the /actual/ reported issue and submit that if the behavior is reproducible. Just ignore me for now ... ;) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel