Mozmill fails to properly initialize metro mode

RESOLVED FIXED

Status

Testing Graveyard
Mozmill
P1
normal
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: Andrei Eftimie, Assigned: Andrei Eftimie)

Tracking

({regression})

Details

(Whiteboard: [mozmill-2.0.3])

(Assignee)

Description

5 years ago
This is how it is failing:

> INFO | metrotestharness.exe | Activation succeeded. processid=7340
> INFO | metrotestharness.exe | Waiting on child process...
> IO Completion Port unexpectedly closed
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> TEST-UNEXPECTED-FAIL | Disconnect Error: Application unexpectedly closed
> RESULTS | Passed: 0
> RESULTS | Failed: 0
> RESULTS | Skipped: 0
> Traceback (most recent call last):
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozmill\__init__.py", line 777, in run
>     mozmill.run(tests, self.options.restart)
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozmill\__init__.py", line 435, in run
>     self.stop()
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozmill\__init__.py", line 538, in stop
>     self.runner.cleanup()
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozrunner\runner.py", line 132, in cleanup
>     self.profile.cleanup()
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozprofile\profile.py", line 129, in cleanup
>     mozfile.remove(self.profile)
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozfile\mozfile.py", line 180, in remove
>     _call_with_windows_retry(shutil.rmtree, path)
>   File "c:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\lib\site-packages\mozfile\mozfile.py", line 152, in _call_with_windows_retry
>     func(path)
>   File "C:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\Lib\shutil.py", line 250, in rmtree
>     onerror(os.remove, fullname, sys.exc_info())
>   File "C:\mozmill-env\2.0.2-windows-clean\mozmill-env\python\Lib\shutil.py", line 248, in rmtree
>     os.remove(fullname)
> WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\user\\appdata\\local\\temp\\tmprizhgn.mozrunner\\cert8.db'
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Exception WindowsError: WindowsError(32, 'The process cannot access the file because it is being used by another process') in <bound method MetroFirefoxRunner.cleanup of <mozrunner.local.MetroFirefoxRunner object at 0x01C84950>> ignored
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Retrying to remove "c:\users\user\appdata\local\temp\tmprizhgn.mozrunner" because it is in use.
> Exception WindowsError: WindowsError(32, 'The process cannot access the file because it is being used by another process') in <bound method MetroFirefoxProfile.__del__ of <mozprofile.profile.MetroFirefoxProfile object at 0x01C651D0>> ignored

Nightly build from Dec 11th works fine
Nightly build from Dec 12th fails

Here is the pushlog from mozilla-central:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=12ea03a70243&tochange=8b5875dc7e31

That is a really big pushlog. It will take a while to narrow it down.
We have several merges from inbound and several merges from fx-central plus lots of commits directly in mc
(Assignee)

Comment 1

5 years ago
Visually Nightly get opened in Metro mode, then just waits. Mozmill fails to properly connect.
(Assignee)

Comment 2

5 years ago
Mario, can you please use tinderbox builds to reduce this regression range further.
Assignee: nobody → mario.garbi
Status: NEW → ASSIGNED
The profile is blocked by the running application so we are not able to remove all the files of that profile. Not sure why the application doesn't close anymore. It's something we have to find out quickly so we can follow-up with a 2.0.3 release of Mozmill.

Not sure yet if the fix is related to Mozmill or Mozrunner.
Assignee: mario.garbi → nobody
Blocks: 950831
Status: ASSIGNED → NEW
Keywords: regression, regressionwindow-wanted
Priority: -- → P1
We want to have Mario on Mozmill tests but not Mozmill. So please investigate tomorrow Andrei.
Do we have any update regarding the regression range?
Also please try with my patch on bug 951628 if that change makes any difference here.
(Assignee)

Comment 7

5 years ago
The fix from bug 951628 does not make a difference here.
(Assignee)

Comment 8

5 years ago
I've been working on (In reply to Henrik Skupin (:whimboo) from comment #5)
> Do we have any update regarding the regression range?

Nope. That's why I asked Mario to do this this morning.
I had to investigate & fix & run tests for the other 2.0 issues until now.
It would have probably been done by now.

I don't understand why you were against him reducing the regression range.
He had the least amount of work on his plate right now, and as you frequently said we should "work as a team, and split work when needed". That's what I was trying to do here.

I'll hopefully have this done today.
(In reply to Andrei Eftimie from comment #8)
> Nope. That's why I asked Mario to do this this morning.
> I had to investigate & fix & run tests for the other 2.0 issues until now.
> It would have probably been done by now.
> 
> I don't understand why you were against him reducing the regression range.

As you may remember we want Mario to work on Mozmill Tests issues only, not on Mozmill. Nothing has been changed here in the last couple of weeks/months. Not sure what Andreea is currently working on but she might have been perfectly picked this up, given that one of her P1 bugs is blocked by that one. Also Cosmin should be free to work on this given that no other important bugs are on his plate. Please get this done ASAP.
No longer blocks: 950831
(Assignee)

Comment 10

5 years ago
This is the changeset:
http://hg.mozilla.org/integration/fx-team/rev/690537e87173

This is bug 946296
Blocks: 946296
(Assignee)

Updated

5 years ago
status-firefox29: --- → affected
Keywords: regressionwindow-wanted
(Assignee)

Comment 11

5 years ago
Ugh, I've tried resetting this pref in mozmill __init__ where we set other prefs, but it doesn't help.
I think we'll need to set ip up further up the chain in mozbase to be able to load mozmill.
(Assignee)

Updated

5 years ago
Depends on: 952420
(Assignee)

Updated

5 years ago
Assignee: nobody → andrei.eftimie
Status: NEW → ASSIGNED
This bug is fixed now with mozprofile 0.19 released.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill-2.0.3]
And we have it as part of Mozmill 2.0.3, which is nice.
Blocks: 950831
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.