Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68289

Re: unittest weirdness

Show all headers | View raw

In article <mailman.8095.1394640002.18130.python-list@python.org>,
 Ethan Furman <ethan@stoneleaf.us> wrote:

> > Alternatively, maybe something inside your process is just calling
> > sys.exit(), or even os._exit().  You'll see the exit() system call in
> > the strace output.
> 
> My bare try/except would have caught that.

A bare except would catch sys.exit(), but not os._exit().  Well, no 
that's not actually true.  Calling os._exit() will raise:

TypeError: _exit() takes exactly 1 argument (0 given)

but it won't catch os._exit(0) :-)

> > what happens if you reduce that to:
> >
> >       def test_xxx_1(self):
> >            self.fail()
> 
> I only get the strange behavior if more than two (or maybe three) of my test 
> cases fail.  Less than that magic number, 
> and everything works just fine.  It doesn't matter which two or three, 
> either.

OK, well, assuming this is a memory problem, what if you do:

      def test_xxx_1(self):
           l = []
           while True:
               l.append(0)

That should eventually run out of memory.  Does that get you the same 
behavior in a single test case?  If so, that at least would be evidence 
supporting the memory exhaustion theory.

> I strongly suspect it's memory.  When I originally wrote the code I tried to 
> include six months worth of EoM data, but 
> had to back it down to three as my process kept mysteriously dying at four or 
> more months.  There must be waaaaaaay too 
> much stuff being kept alive by the stack traces of the failed tests.

One thing you might try is running your tests under nose 
(http://nose.readthedocs.org/).  Nose knows how to run unittest tests, 
and one of the gazillion options it has is to run each test case in an 
isolated process:

  --process-restartworker
                If set, will restart each worker process once their
                tests are done, this helps control memory leaks from
                killing the system. [NOSE_PROCESS_RESTARTWORKER]

that might be what you need.

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

unittest weirdness Ethan Furman <ethan@stoneleaf.us> - 2014-03-11 13:58 -0700
  Re: unittest weirdness John Gordon <gordon@panix.com> - 2014-03-11 22:13 +0000
    Re: unittest weirdness Ethan Furman <ethan@stoneleaf.us> - 2014-03-11 15:29 -0700
    Re: unittest weirdness Terry Reedy <tjreedy@udel.edu> - 2014-03-11 23:36 -0400
    Re: unittest weirdness Ethan Furman <ethan@stoneleaf.us> - 2014-03-12 03:03 -0700
      Re: unittest weirdness Roy Smith <roy@panix.com> - 2014-03-12 09:44 -0400
        Re: unittest weirdness Ethan Furman <ethan@stoneleaf.us> - 2014-03-12 08:32 -0700
          Re: unittest weirdness Roy Smith <roy@panix.com> - 2014-03-12 13:48 -0400
          Re: unittest weirdness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-12 23:14 +0000
          Re: unittest weirdness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-12 23:47 +0000
            Re: unittest weirdness Ethan Furman <ethan@stoneleaf.us> - 2014-03-12 17:31 -0700
        Re: unittest weirdness Terry Reedy <tjreedy@udel.edu> - 2014-03-12 22:27 -0400
  Re: unittest weirdness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-12 23:38 +0000
    Re: unittest weirdness Ethan Furman <ethan@stoneleaf.us> - 2014-03-12 17:36 -0700

csiph-web