Closed Bug 578448 Opened 10 years ago Closed 10 years ago

browser_bug435788.js consistently times out in Test 1 on Windows 7 tinderboxen

Categories

(Toolkit Graveyard :: Plugin Finder Service, defect)

x86
Windows 7
defect
Not set

Tracking

(blocking2.0 beta3+)

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta3+

People

(Reporter: mossop, Assigned: mossop)

References

Details

(Keywords: intermittent-failure, Whiteboard: [win7])

Attachments

(2 files)

TEST-START | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js
TEST-PASS | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Test 1
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | PFS loaded
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Page shown: Welcome to the Plugin Finder Service
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button next. hidden: false, disabled: false
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button finish. hidden: false, disabled: false
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | wizardnext event
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Page shown: Available Plugin Downloads
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button next. hidden: false, disabled: false
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button finish. hidden: false, disabled: false
TEST-PASS | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Should have found 1 plugin to install
TEST-PASS | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Should have seen the right plugin name
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | wizardnext event
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Page shown: Plugin Licenses
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button next. hidden: false, disabled: false
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button finish. hidden: false, disabled: false
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | wizardnext event
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Page shown: Installing Plugins
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button next. hidden: false, disabled: false
TEST-INFO | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Button finish. hidden: false, disabled: false
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/mozapps/plugins/tests/browser_bug435788.js | Timed out
Whiteboard: [win7][orange]
Mossop - your name's on this one - are you likely to fix it soon or should we be looking for another owner?
You can find current logs for this by going to:
http://tests.themasta.com/tinderboxpushlog/?noignore=1
and looking for the "Mo (oth)" build on the Win7 line.
(In reply to comment #1)
> Mossop - your name's on this one - are you likely to fix it soon or should we
> be looking for another owner?

I have been stuck with b2 blocker work thus far and all I have been able to determine is that this test passes just fine on my Win7 box. A new owner would be great but I don't know of anyone else who knows this code.
I can loan a Win7 testing machine if need be.
This is one of a small number of bugs which block us from unhiding the win7 test boxes, and shipping on win7 is in plan for FF4, so some kind of fix here is a blocker, and should happen near term, hence the beta3+ flag.
blocking2.0: --- → beta3+
(In reply to comment #4)
> I can loan a Win7 testing machine if need be.

Ok, let's do that and see if I can see what is going on here.
(In reply to comment #6)
> (In reply to comment #4)
> > I can loan a Win7 testing machine if need be.
> 
> Ok, let's do that and see if I can see what is going on here.
>
After IRC conversation I believe dolske or someone else might take this. Please file a bug once you (or someone else) is ready to work on this and I should get you the machine pretty fast. See bug 578372 for reference.
This also passes for me on my Win7 box... I see some asserts being fired, but these seem to be after the point where the logs say the hang happens.

Armen: can you reproduce by running tests manually on a production Win7 test box? ("make mochitest-browser-chrome" in objdir)? If so, we'll probably need access to a testing machine to track down what's different.
(In reply to comment #8)

> Armen: can you reproduce by running tests manually on a production Win7 test
> box? ("make mochitest-browser-chrome" in objdir)? If so, we'll probably need
> access to a testing machine to track down what's different.

ping?
We don't have an objdir on the test slaves but we unzip the packaged tests.
I have written a simple bat file that follows what we do on our testing machines through buildbot. This file should help you out to get things going fast.

I have tried running manually and tried to used a known build
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1279800966.1279803072.8708.gz&fulltext=1
http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1279797102
but I am crashing on browser_settitle.js and therefore not reaching browser_bug435788.js.

Please let me know if I can now pass you the machine.

REM nircmd.exe setdisplay 1280 1024 32
SET FTP_SERVER=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32
SET ID=1279797102
SET PATH=C:\mozilla-build;C:\mozilla-build\msys\bin;C:\mozilla-build\msys\local\bin;C:\mozilla-build\Python25;C:\mozilla-build\Python25\Scripts;C:\mozilla-build\hg;C:\mozilla-build\7zip;C:\mozilla-build\upx203w;C:\WINDOWS\System32;C:\WINDOWS;
SET MINIDUMP_STACKWALK=c:/talos-slave/mozilla-central-win7-opt-u-mochitest-other/tools/breakpad/win32/minidump_stackwalk.exe
cd c:\talos-slave\mozilla-central-win7-opt-u-mochitest-other
rm -rf tools
hg clone http://hg.mozilla.org/build/tools tools
rm -rf build
mkdir build && cd build
wget --progress=dot:mega -N %FTP_SERVER%/%ID%/firefox-4.0b3pre.en-US.win32.zip
wget --progress=dot:mega -N %FTP_SERVER%/%ID%/firefox-4.0b3pre.en-US.win32.tests.zip
REM mkdir symbols && cd symbols && wget --progress=dot:mega -N %FTP_SERVER%/%ID%/firefox-4.0b3pre.en-US.win32.crashreporter-symbols.zip && cd ..
unzip -o firefox-4.0b3pre.en-US.win32.zip
unzip -o firefox-4.0b3pre.en-US.win32.tests.zip
REM unzip -o firefox-4.0b3pre.en-US.win32.crashreporter-symbols.zip
C:\Windows\system32\cmd.exe /c python mochitest/runtests.py --appname=firefox/firefox.exe --utility-path=bin --extra-profile-file=bin/plugins --certificate-path=certs --autorun --close-when-done --console-level=INFO --symbols-path=symbols --browser-chrome | tee ../browser-chrome.log
(In reply to comment #10)
> Created attachment 459504 [details]
> log of manual run on talos r3 machine
> 
> We don't have an objdir on the test slaves but we unzip the packaged tests.
> I have written a simple bat file that follows what we do on our testing
> machines through buildbot. This file should help you out to get things going
> fast.
> 
> I have tried running manually and tried to used a known build
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1279800966.1279803072.8708.gz&fulltext=1
> http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1279797102
> but I am crashing on browser_settitle.js and therefore not reaching
> browser_bug435788.js.

It hardly sounds promising that you are unable to reproduce the same results as a real tinderbox run on this machine but I guess if that is as far as you can get then I can try it out.
I managed to reproduce it. This time I closed the VNC connection with the machine after triggering the script and when I came back I got to see what was going on.

Here is a screen shot of what is going on.

I will attach the log on the next attachement

NOTE on the side: If we took a snap shot before rebooting and uploading it with the builds we would have noticed this right away.
This looks to be PGO related. Seems that the build on Windows 2003 is creating a dependency in this simple exe to pgort80.dll which isn't available on Windows 7. Ted, do you know anything about this?
I think maybe there's a bug on file on this. SIMPLE_PROGRAMs don't get relinked in the second phase of the PGO build, so they wind up linked to pgort80.dll, which is part of the PGO runtime system from VC++, and not available if you don't have the compiler installed.
Depends on: 542504
Since we know the test does actually work (when run locally), how about we just disable this test for Windows 7 for now, and reenable it after bug 542504 is fixed?
This should be fixed now, Armen can you verify that?
I just clobbered the Windows opt builds after landing bug 542504, so you should be able to check after we get builds from that.
http://tests.themasta.com/tinderboxpushlog/?noignore=1 shows that it's fixed now, though we still can't unhide mochitest-other due to bug 581734 and possibly some intermittent mochitest-browser-chrome timeouts.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 438871
Whiteboard: [win7][orange] → [win7]
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.