420183 - vista talos machines didn't properly close browser.

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Robert Sayre]

They're complaining they can't write to a temp directory

Comment 1

[Robert Sayre]

Tree is closed until they come back, but also closed for other reasons at the moment.

Comment 2

[matthew zeier [:mrz]]

Paged Alice - not sure what can/should be removed.

Comment 3

[alice nodelman [:alice] [:anode]]

The error is indicating that the browser was still open when talos attempted to clean up the profile directory that it was using - so could be a browser crash or a fluke.

I'd like to see another cycle of the machine to see if there really is a persistent problem.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

For these cases, would it help to rename the profile out of the way to some random string, and then delete it?  If that fails then we have some profile crud left over, but it won't interfere with running the next test.

Comment 5

[Robert Sayre]

(In reply to comment #3)
> 
> I'd like to see another cycle of the machine to see if there really is a
> persistent problem.

Can you start another cycle?

Comment 6

[alice nodelman [:alice] [:anode]]

Unfortunately, there are no pending builds.  We don't have a system in place yet to force testing of a previous build so we end up stuck until a new build appears.

I have some possible fixes pending for this involving ensuring that the browser is closed and if not then failing in a graceful manner without attempting to remove the profile.

Comment 7

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Another (unrelated) browser code problem caused qm-centos5-01 to go orange, and was corrected, so now ok to ignore.

Specifically qm-mini-vista05 and qm-mini-vista02 are still burning and need to be fixed.

Comment 8

[Jesse Ruderman]

(In reply to comment #4)
> For these cases, would it help to rename the profile out of the way to some
> random string, and then delete it?  If that fails then we have some profile
> crud left over, but it won't interfere with running the next test.

Having the old browser still open might affect the perf results of the next test...

Comment 9

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Interesting that two machines failed out with same error at the same time.


qm-mini-vista02 failed out with:
OSError: [Errno 13] Permission denied: 'c:\\users\\mozill~1\\appdata\\local\\temp\\tmpkyhi-l\\profile\\Cache\\_CACHE_001_'


qm-mini-vista05 failed out with:
OSError: [Errno 13] Permission denied: 'c:\\users\\mozill~1\\appdata\\local\\temp\\tmpek4k6h\\profile\\Cache\\_CACHE_001_'

Comment 10

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

From debugging with alice:

1) For some unknown reason, the two talos vista machines hiccuped. There was some remnants of a browser error dialog, but unknown how old. We believe this is fallout from the "buildbot doesnt always kill subprocesses on win32" problem in bug#416863. We believe the machines are ok now, and will turn green, when they test another build.

2) There is currently no way to resend a pre-existing build to these machines (bug#291167), so we have to wait for a new build to be produced.

3) The win32 builders are running much slower now that PGO is enabled (bug#418865). However, as I was writing this, another win32 build just popped out, and is now being processed by the vista talos boxes.

Comment 11

[alice nodelman [:alice] [:anode]]

The immediate issue with these vista boxes was fixed and they are now green.  The problems with talos not properly killing browser processes can be tracked in other bugs (bug 416863, bug 419492, bug 420216).