On Mon, Sep 28, 2015 at 04:31:12PM +0200, Cyril Brulebois wrote:
> Ole Streicher <olebole@debian.org> (2015-09-28):
> > The CI tests run here are the same as in during the build process, where
> > they succeed. Since it is a specific test that fails, I guess that it is
> > not just the different location (build tree vs. installed version), but
> > the environment that is different. Specifically, I guess that the
> > problem is the following python test [2]:
> >
> > --------------------------------8<--------------------------------------
> > PY3_4 = sys.version_info[:2] >= (3, 4)
> >
> > # Used for the below test--inline functions aren't pickleable
> > # by multiprocessing?
> > def _square(x):
> > return x ** 2
> >
> > @pytest.mark.skipif('not PY3_4 or sys.platform == "win32" or sys.platform.startswith("gnu0")')
> > def test_multiprocessing_forkserver():
> > """
> > Test that using multiprocessing with forkserver works. Perhaps
> > a simpler more direct test would be to just open some local
> > sockets and pass something through them.
> >
> > Regression test for https://github.com/astropy/astropy/pull/3713
> > """
> >
> > import multiprocessing
> > ctx = multiprocessing.get_context('forkserver')
> > pool = ctx.Pool(1)
> > result = pool.map(_square, [1, 2, 3, 4, 5])
> > pool.close()
> > pool.join()
> > assert result == [1, 4, 9, 16, 25]
> > --------------------------------8<--------------------------------------
> >
> > Is there a reason why this could block in the CI context?
>
> A common issue with multiprocessing is the lack of /dev/shm; you would
> usually get something like "function not implemented" though. You may
> want to check things like:
> https://docs.python.org/dev/library/multiprocessing.html
> https://bugs.python.org/issue3770
the CI environment does have /dev/shm, so I don't think that would be
the problem. given the fact that the tests pass just fine under python2
but not under python3, I would start by investigating the difference in
requirements for that code between the python versions.
if you can reproduce the issue locally (you probably want to reduce the
timeout from the default of 2h), you can pass --shell-fail to adt-run,
you will get a shell in the testbed, when you will be able to fiddle
around and try to figure out what the problem is.
--
Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: PGP signature