New issue
Advanced search Search tips

Issue 767173 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

workqueue/tasks/tasks_unittest produces random noise that looks like failure

Reported by jrbarnette@chromium.org, Sep 20 2017

Issue description

Sometimes, when running the unit tests in lib/workqueue/tasks_unittest.py,
you get random failures like this:

======================================================================
ERROR: [chromite.lib.workqueue.tasks_unittest] ProcessPoolTaskManagerTests.testTerminateThenRun
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/host/source/chromite/lib/cros_test_lib.py", line 262, in _stacked_setUp
    StackedSetup._stacked_tearDown(obj)
  File "/mnt/host/source/chromite/lib/cros_test_lib.py", line 278, in _stacked_tearDown
    target(obj)
  File "/mnt/host/source/chromite/lib/workqueue/tasks_unittest.py", line 61, in tearDown
    self._task_manager.Close()
AttributeError: 'ProcessPoolTaskManagerTests' object has no attribute '_task_manager'

Debug (in the form of printing "os.getpid()" shows that these exceptions are
coming from child processes of the main unit test process.  Presumably these
are the subprocesses created by the 'multiprocessing.Pool' object owned by
`self._task_manager`.

 
Components: Infra>Client>ChromeOS
Status: Available (was: Untriaged)
Digging a bit deeper, the messages above also include text like this:

----------------------------------------------------------------------
Ran 14 tests in 46.565s

FAILED (errors=4)

... All well and good, but the last thing that gets printed is a repeat:

----------------------------------------------------------------------
Ran 14 tests in 59.140s

OK


Aaand exit status from the unit test command is 0; for failure it would
be 1.  So, because the messages come from the child, they're actually
mere noise, and not recorded as failures.
Finally, it seems like changing `multiprocessing.Pool.terminate` to
`multiprocessing.Pool.close` makes the problem go away.  It's hard
to know for sure, since the problem is intermittent so "didn't see a
failure" isn't the same as "the bug isn't there".

Summary: workqueue/tasks/tasks_unittest produce random noise that looks like failure (was: workqueue/tasks/tasks_unittest fails because of subprocesses)
Summary: workqueue/tasks/tasks_unittest produces random noise that looks like failure (was: workqueue/tasks/tasks_unittest produce random noise that looks like failure)
Hi, this bug has not been updated recently. Please acknowledge the bug and provide status within two weeks (6/22/2018), or the bug will be archived. Thank you.

Sign in to add a comment