In article <mailman.8095.1394640002.18130.python-l...@python.org>,
Ethan Furman <et...@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.
--
https://mail.python.org/mailman/listinfo/python-list
