519540 - Mozmill script runs forever if process id overflows / gets reset [@ group_wait]

Status: RESOLVED WORKSFORME

(Testing :: Mozbase, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

If you are using your system over a couple of days the process id will overflow and start by 0 again. In such a condition mozrunner is not able to kill the process and Firefox will not shutdown. This can be a major problem on buildbot.

Killing the Python process will show the following traceback:

Traceback (most recent call last):
  File "/usr/local/bin/mozmill", line 8, in <module>
    load_entry_point('mozmill==1.2.1.1', 'console_scripts', 'mozmill')()
  File "/Volumes/data/build/tools/mozmill/mozmill/__init__.py", line 409, in cli
    CLI().run()
  File "/Volumes/data/build/tools/mozmill/mozmill/__init__.py", line 377, in run
    m.stop()
  File "/Volumes/data/build/tools/mozmill/mozmill/__init__.py", line 176, in stop
    self.runner.wait()
  File "build/bdist.macosx-10.5-i386/egg/mozrunner/__init__.py", line 463, in wait
  File "build/bdist.macosx-10.5-i386/egg/mozrunner/killableprocess.py", line 227, in wait
  File "build/bdist.macosx-10.5-i386/egg/mozrunner/killableprocess.py", line 221, in group_wait

Comment 1

[Jesse Ruderman]

Why does the process ID overflow prevent mozmill from killing Firefox?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

My comment 0 was probably a bit wrong. Firefox gets closed but the Python script hangs forever in group_wait. So the script doesn't quit and not the browser. Sorry.

Comment 3

[cmtalbert]

Is this still an issue?  Doesn't the timeout global timeout in the python side ensure we'll destroy this process (because the python script will exit itself once the timeout is up).

--> WFM?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Clint, please see comment 2. We close the browser but the python script hangs. I wasn't able yet to determine if it could be fixed. We definitely shouldn't have it on our 1.4.2 plate. Seems like only my system is affected by that and I have to wait until it happens again. So please leave it open for now.

Comment 6

[Jeff Hammel]

checking bug status as this is listed as a blocker for bug 516984 . Is this still an issue?  Is this still a blocker?

Comment 7

[cmtalbert]

(In reply to comment #6)
> checking bug status as this is listed as a blocker for bug 516984 . Is this
> still an issue?  Is this still a blocker?
This is only reproducible on Henrik's machine.  We've never been able to repro it anywhere else, so no, I don't think this should be considered a blocker.

Comment 8

[Jeff Hammel]

(In reply to comment #7)
> (In reply to comment #6)
> > checking bug status as this is listed as a blocker for bug 516984 . Is this
> > still an issue?  Is this still a blocker?
> This is only reproducible on Henrik's machine.  We've never been able to repro
> it anywhere else, so no, I don't think this should be considered a blocker.

If we're going to proceed with bug 516984, then someone should make this decision.  I'm content marking it as closed if it does not occur in a buildbot staging environment.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #8)
> If we're going to proceed with bug 516984, then someone should make this
> decision.  I'm content marking it as closed if it does not occur in a buildbot
> staging environment.

Lets remove it from the 1.5.1 list but please leave it open. Once I trigger the issue again, I will work on a stack trace with more information.

Comment 10

[Jeff Hammel]

(In reply to comment #9)
> (In reply to comment #8)
> > If we're going to proceed with bug 516984, then someone should make this
> > decision.  I'm content marking it as closed if it does not occur in a buildbot
> > staging environment.
> 
> Lets remove it from the 1.5.1 list but please leave it open. Once I trigger the
> issue again, I will work on a stack trace with more information.

The real question is should this be a blocker for bug 516984?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As long as we can't reproduce on other machines, I wouldn't mark it as blocker for bug 516984. There are no clear reproduction steps available at the moment because it happens so rarely. Our QA lab boxes also never suffered from it. So I would really say, don't worry about it.

Comment 12

[Jeff Hammel]

(In reply to comment #11)
> As long as we can't reproduce on other machines, I wouldn't mark it as blocker
> for bug 516984. There are no clear reproduction steps available at the moment
> because it happens so rarely. Our QA lab boxes also never suffered from it. So
> I would really say, don't worry about it.

blocker removed

Comment 13

[Jeff Hammel]

still an issue?

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Haven't seen it for a long time. Could have been fixed by one of the changes how we handle the killable process. Lets resolve as WFM. I will reopen, when it re-appears and I have clear steps.