643491 - Updates tests fail for Xulrunner:application.ini on Windows 2000

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[u279076]

Attachment: Update log

I've only been able to reproduce this in Windows 2000 with Firefox 4.0betaX/rc1 -> 4.0final updates.  The updates appear to dowload and install properly but during one of the restart phases (not sure which one), XULRunner throws an "Couldn't read application.ini" error dialog.

I'm also see multiple errors in the logfile like the following:
error removing c:\docume~1\mozilla\locals~1\temp\tmpinyp7d.mozrunner: c:\docume~1\mozilla\locals~1\temp\tmpinyp7d.mozrunner\permissions.sqlite: The process cannot access the file because it is being used by another process

I'll attach the sample log file.

Comment 1

[u279076]

It should be noted that we don't get the same error when running major update for 3.5/3.6 -> 4.0final.

Comment 2

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

Have you checked that box that no other python process is running? As best restart it to make sure. Looks like something else is blocking us. Not sure yet if this error dialog is related.

Comment 3

[u279076]

Yes.  I've retried after closing any open python processes.  I've even rebooted the VM -- it still happens, but only for 4.x -> 4.0 updates, not 3.5/3.6.

Comment 4

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

This teardownModule disconnect is related to content we push into the persisted object. I will have to look a bit deeper which specific data is causing this bug.

Comment 5

[Jeff Hammel]

Not sure if this helps but :ahal discovered in bug 533857 that pushing too much data over the JSbridge won't work

Comment 6

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

(In reply to comment #5)
> Not sure if this helps but :ahal discovered in bug 533857 that pushing too much
> data over the JSbridge won't work

Yes, that's exactly my issue here. But I don't have that much data. Do we already know what the limit is? That's kinda blocking us for at least update tests. We should fix this and probably have to release a new hotfix version of Mozmill 1.5.x. Do we already have a Mozmill bug?

Comment 7

[Jeff Hammel]

Outside of bug 533867 I am not aware of a bug for this.  We don't know the limit; worse, we don't really know why the problem occurs. I've only stood over :ahal's shoulders as he's examined the problem, so I'm not very knowledge nor do I know how much he looked at it.  Without a diagnosis, it is impossible to know if the fix is easy or difficult.  About all I know is my naive guess of sleeping after transfering the persisted data does not work.

Comment 8

[Andrew Halberstadt [:ahal]]

In regards to the jsbridge data bug I think Heather knows the most out of any of us, but I'm not sure how much if anything she discovered.

Heather, did we end up filing a separate bug for it?

Comment 9

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

Lets not overstress this bug. I will file a new one for the JSbridge issue so we can get it fixed on the Mozmill side.

Anthony, I wouldn't like to backout the latest additions we have made lately on bug 640369. Do you think it's manageable for the time being on Windows 2000? If not I would prefer to patch it outside of the usual release test folder.

Comment 10

[u279076]

It's certainly manageable for the time being. It just means we have to manually spotcheck on Win2000.

Comment 11

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

Clint is investigating this issue now on bug 643697. AFAICS it shouldn't affect our major update tests from older branches.

Comment 12

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

Tested on qa-set with the fix in place for Mozmill 1.5.3 and it works perfectly now.

I have updated qa-set and qa-horus to mozmill 1.5.3 RC.