Closed Bug 1529331 Opened 7 years ago Closed 7 years ago

Permafailing tier 2 testing/mozbase/mozprocess/tests/test_poll.py::ProcTestPoll::test_poll_after_kill_no_process_group TEST-UNEXPECTED-FAIL

Categories

(Testing :: Mozbase, defect, P5)

Version 3
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1532630

People

(Reporter: intermittent-bug-filer, Assigned: tarek)

References

Details

(Keywords: intermittent-failure, regression, Whiteboard: [stockwell unknown])

#[markdown(off)]
Filed by: ncsoregi [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=229434209&repo=autoland

https://queue.taskcluster.net/v1/task/fvYKZuEUTZCTwMxWS48acQ/runs/0/artifacts/public/logs/live_backing.log

[task 2019-02-20T14:07:42.207Z] 0:52.54 testing/mozbase/mozprocess/tests/test_poll.py::ProcTestPoll::test_poll_after_kill_no_process_group TEST-UNEXPECTED-FAIL
[task 2019-02-20T14:07:42.207Z] 0:52.54 testing/mozbase/mozprocess/tests/test_poll.py::ProcTestPoll::test_poll_before_run PASSED
[task 2019-02-20T14:07:42.207Z] 0:52.54 testing/mozbase/mozprocess/tests/test_poll.py::ProcTestPoll::test_poll_while_running PASSED
[task 2019-02-20T14:07:42.207Z] 0:52.54
[task 2019-02-20T14:07:42.207Z] 0:52.54 =================================== FAILURES ===================================
[task 2019-02-20T14:07:42.207Z] 0:52.54 ______________ ProcTestPoll.test_poll_after_kill_no_process_group ______________
[task 2019-02-20T14:07:42.207Z] 0:52.54
[task 2019-02-20T14:07:42.207Z] 0:52.54 self = <test_poll.ProcTestPoll testMethod=test_poll_after_kill_no_process_group>
[task 2019-02-20T14:07:42.207Z] 0:52.54
[task 2019-02-20T14:07:42.207Z] 0:52.54 def test_poll_after_kill_no_process_group(self):
[task 2019-02-20T14:07:42.207Z] 0:52.54 """Process (no group) is killed, and poll() is called."""
[task 2019-02-20T14:07:42.207Z] 0:52.54 p = processhandler.ProcessHandler([self.python, self.proclaunch,
[task 2019-02-20T14:07:42.208Z] 0:52.54 "process_normal_finish_no_process_group.ini"],
[task 2019-02-20T14:07:42.208Z] 0:52.54 cwd=here,
[task 2019-02-20T14:07:42.208Z] 0:52.54 ignore_children=True
[task 2019-02-20T14:07:42.208Z] 0:52.54 )
[task 2019-02-20T14:07:42.208Z] 0:52.54 p.run()
[task 2019-02-20T14:07:42.208Z] 0:52.54 > returncode = p.kill()
[task 2019-02-20T14:07:42.208Z] 0:52.54
[task 2019-02-20T14:07:42.208Z] 0:52.54 testing/mozbase/mozprocess/tests/test_poll.py:70:
[task 2019-02-20T14:07:42.208Z] 0:52.54 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[task 2019-02-20T14:07:42.208Z] 0:52.54 testing/mozbase/mozprocess/mozprocess/processhandler.py:812: in kill
[task 2019-02-20T14:07:42.208Z] 0:52.54 self.proc.kill(sig=sig)
[task 2019-02-20T14:07:42.208Z] 0:52.54 testing/mozbase/mozprocess/mozprocess/processhandler.py:208: in kill
[task 2019-02-20T14:07:42.208Z] 0:52.54 self.returncode = self.wait()
[task 2019-02-20T14:07:42.209Z] 0:52.54 testing/mozbase/mozprocess/mozprocess/processhandler.py:229: in wait
[task 2019-02-20T14:07:42.209Z] 0:52.54 self.returncode = self._wait()
[task 2019-02-20T14:07:42.209Z] 0:52.54 testing/mozbase/mozprocess/mozprocess/processhandler.py:665: in _wait
[task 2019-02-20T14:07:42.209Z] 0:52.54 subprocess.Popen.wait(self)
[task 2019-02-20T14:07:42.210Z] 0:52.55 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[task 2019-02-20T14:07:42.210Z] 0:52.55
[task 2019-02-20T14:07:42.211Z] 0:52.55 self = <mozprocess.processhandler.ProcessHandlerMixin.Process object at 0x10fad32e8>
[task 2019-02-20T14:07:42.211Z] 0:52.55 timeout = None
[task 2019-02-20T14:07:42.211Z] 0:52.55
[task 2019-02-20T14:07:42.211Z] 0:52.55 def wait(self, timeout=None):
[task 2019-02-20T14:07:42.211Z] 0:52.55 """Wait for child process to terminate; returns self.returncode."""
[task 2019-02-20T14:07:42.211Z] 0:52.55 if timeout is not None:
[task 2019-02-20T14:07:42.211Z] 0:52.55 endtime = _time() + timeout
[task 2019-02-20T14:07:42.212Z] 0:52.55 try:
[task 2019-02-20T14:07:42.212Z] 0:52.55 > return self._wait(timeout=timeout)
[task 2019-02-20T14:07:42.212Z] 0:52.55 E TypeError: _wait() got an unexpected keyword argument 'timeout'
[task 2019-02-20T14:07:42.212Z] 0:52.55
[task 2019-02-20T14:07:42.212Z] 0:52.55 /tools/python37/lib/python3.7/subprocess.py:984: TypeError

Could be related to bug 1428713.

It appears that Python has been updated to 3.7.1 on macOS, which has caused this failure.

Dave, would you have the time to have a look into this failure?

Flags: needinfo?(dave.hunt)

Sorry, I do not. As mentioned in comment 7 the Python version on the macOS hardware has been updated to 3.7.1, which has introduced this failure. We either need to track down and revert that change, or we need to update moz(process|base) to support Pyhton 3.7.

Another option might be to ensure Python 3.5 is also available on our macOS hardware and restrict these tests to run on that version. I'm not sure who can answer regarding the Python versions on macOS, and the process for updating them.

Flags: needinfo?(dave.hunt)

Joel or Geoff, do you know who did that upgrade? Was it intentional? It feels strange given that we leave behind perma failures.

Flags: needinfo?(jmaher)
Flags: needinfo?(gbrown)

I am not aware of any python upgrades on the machines

:dividehex, do you know more about the python version on the osx machines?

Flags: needinfo?(jmaher) → needinfo?(jwatkins)
Flags: needinfo?(gbrown)

Not convinced it will work as it depends on a) Python 3.5 still being available on the macOS workers and b) Pipenv being able to locate Python 3.5 but I've pushed a patch to try that forces these tests to run on Python 3.5: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dfea6b543dde3d60bfe7882bb5daf66f3926565b

If Python 3.5 is indeed still available on the workers, then we may need to understand why Pipenv isn't locating it. There have been new releases of Pipenv, and I believe it now uses pythonfinder to locate Python on the system. Perhaps we could consider vendoring this, or implementing something similar ourselves.

(In reply to Dave Hunt [:davehunt] [he/him] ⌚️UTC from comment #11)

Not convinced it will work as it depends on a) Python 3.5 still being available on the macOS workers and b) Pipenv being able to locate Python 3.5 but I've pushed a patch to try that forces these tests to run on Python 3.5: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dfea6b543dde3d60bfe7882bb5daf66f3926565b

If Python 3.5 is indeed still available on the workers, then we may need to understand why Pipenv isn't locating it. There have been new releases of Pipenv, and I believe it now uses pythonfinder to locate Python on the system. Perhaps we could consider vendoring this, or implementing something similar ourselves.

My try push is failing on Windows due to "Python 3.5 was not found on your system…" and it looks like we're running Python 3.6 for recent jobs on Windows. The macOS jobs are still pending, but the Linux jobs passed. We should pick a Python version and make sure it's available across all of our platforms.

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #10)

I am not aware of any python upgrades on the machines

:dividehex, do you know more about the python version on the osx machines?

Releng requested it in bug 1501497. Also relevant (and what spurred it): https://wiki.mozilla.org/ReleaseEngineering/Python_Standards#Updates

This feels to me like a disconnect between release engineering and testing/automation. /cc catlee

Flags: needinfo?(jwatkins)

Yes, the intent is to always have up-to-date versions of python installed on the systems...but not at the expense of breaking things.

Non-virtualized hardware workers make this particularly challenging, as we have to support everything from trunk to ESR branches in the same environment.

Would one option be to make python3.5 available in parallel with python3.7?

(In reply to Chris AtLee [:catlee] from comment #14)

Would one option be to make python3.5 available in parallel with python3.7?

Yes, that should work and Pipenv is meant to be able to locate it. I think it looks for a python3.5 binary in the path. My try push in comment 12 sets the desired Python version to 3.5 but it's failing on Win10 and macOS because it's not found.

I added Bug 1532630 without knowing this one existed. Sorry!

I have a patch that should work on all py version by accepting the timeout option if provided.

See Also: → 1534647

In the last 7 days there have been 57 occurrences on Mac OSX 64 opt.

Over the last 7 days there have been 37 occurence on macosx64.

Here is the most recent failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=235635968&repo=mozilla-inbound&lineNumber=383

Flags: needinfo?(gbrown)

(In reply to Tarek Ziadé (:tarek) from comment #19)

I added Bug 1532630 without knowing this one existed. Sorry!

I have a patch that should work on all py version by accepting the timeout option if provided.

:tarek - Are you going to go ahead with your solution in bug 1532630? (I think it will be okay if you just correct the seconds/milliseconds issue.)

Flags: needinfo?(gbrown) → needinfo?(tarek)

Yes, sorry I was busy on other stuff, will try to finish it this week

Flags: needinfo?(tarek)
Assignee: nobody → tarek
Whiteboard: [stockwell disable-recommended] → [stockwell needswork:owner]

NOte that https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=235635968&repo=mozilla-inbound&lineNumber=383 is yet another failure on the _ssl modulde. This is unrelated to my mozprocess fix

Yes, test_poll_after_kill_no_process_group is fine now - thanks!

The ssl failure continues: bug 1534647.

Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
See Also: → 1552777

These 3 are all misclassifications

task 2019-05-13T09:50:48.759Z]  0:41.29 /Users/cltbld/tasks/task_1557740802/checkouts/gecko/testing/mozbase/mozfile/tests/test_load.py
[task 2019-05-13T09:50:48.759Z]  0:41.29 Traceback (most recent call last):
[task 2019-05-13T09:50:48.759Z]  0:41.29   File "/Users/cltbld/tasks/task_1557740802/checkouts/gecko/testing/mozbase/mozfile/tests/test_load.py", line 12, in <module>
[task 2019-05-13T09:50:48.759Z]  0:41.29     from wptserve.handlers import handler
[task 2019-05-13T09:50:48.760Z]  0:41.29   File "/Users/cltbld/tasks/task_1557740802/checkouts/gecko/testing/web-platform/tests/tools/wptserve/wptserve/__init__.py", line 1, in <module>
[task 2019-05-13T09:50:48.762Z]  0:41.29     from .server import WebTestHttpd, WebTestServer, Router  # noqa: F401
[task 2019-05-13T09:50:48.762Z]  0:41.29   File "/Users/cltbld/tasks/task_1557740802/checkouts/gecko/testing/web-platform/tests/tools/wptserve/wptserve/server.py", line 6, in <module>
[task 2019-05-13T09:50:48.762Z]  0:41.29     import ssl
[task 2019-05-13T09:50:48.763Z]  0:41.29   File "/tools/python37/lib/python3.7/ssl.py", line 98, in <module>
[task 2019-05-13T09:50:48.763Z]  0:41.29     import _ssl             # if we can't import it, let the error propagate
[task 2019-05-13T09:50:48.763Z]  0:41.29 ModuleNotFoundError: No module named '_ssl'
[task 2019-05-13T09:50:48.763Z]  0:41.29 TEST-UNEXPECTED-FAIL | No test output (missing mozunit.main() call?): /Users/cltbld/tasks/task_1557740802/checkouts/gecko/testing/mozbase/mozfile/tests/test_load.py

Filed Bug 1552777.

Issues with the logging: ModuleNotFoundError not being used in suggestions, time stamp part of bug filer's suggestion for summary which warns if you attempt to remove it.

You need to log in before you can comment on or make changes to this bug.