A week, perhaps, ago, I was able to run the jetperf on windows: (mozharness) C:\Users\jhammel\mozharness\src\mozharness>python scripts\jetperf.p y --config-file configs\jetperf\test_config.py --binary-path "c:\Program Files ( x86)\Mozilla Firefox\firefox.exe" Now I get: 16:26:33 ERROR - Traceback (most recent call last): 16:26:33 INFO - File "C:\Users\jhammel\mozharness\src\mozharness\build\ve nv\Scripts\talos-script.py", line 9, in <module> 16:26:33 INFO - load_entry_point('talos==0.0', 'console_scripts', 'talo s')() 16:26:33 INFO - File "C:\Users\jhammel\mozharness\src\mozharness\build\ve nv\lib\site-packages\talos\run_tests.py", line 295, in main 16:26:33 INFO - run_tests(parser) 16:26:33 INFO - File "C:\Users\jhammel\mozharness\src\mozharness\build\ve nv\lib\site-packages\talos\run_tests.py", line 271, in run_tests 16:26:33 INFO - talos_results.output(results_urls, **results_options) 16:26:33 INFO - File "C:\Users\jhammel\mozharness\src\mozharness\build\ve nv\lib\site-packages\talos\results.py", line 78, in output 16:26:33 INFO - _output.output(results, url) 16:26:33 INFO - File "C:\Users\jhammel\mozharness\src\mozharness\build\ve nv\lib\site-packages\talos\output.py", line 67, in output 16:26:33 INFO - f = file(results_path, 'w') 16:26:33 INFO - IOError: [Errno 22] invalid mode ('w') or filename: '' 16:26:33 ERROR - Return code: 1 16:26:33 FATAL - Results file not found: C:\Users\jhammel\mozharness\src\mozh arness\build\jetperf.txt 16:26:33 FATAL - Exiting -1 So I'm not sure what the problem is or what has changed. I would like to add debugging output to talos to help figure this out. Then we can figure out if this is a talos bug, a jetperf bug, or ...

Comment on attachment 662235 [details] [diff] [review] more verbosity Review of attachment 662235 [details] [diff] [review]: ----------------------------------------------------------------- ::: talos/output.py @@ +70,5 @@ > + f.write(str(result)) > + f.close() > + except Exception, e: > + print "results_url: %s" % results_url > + print "results_path: %s" % results_path could we explain that there was an exception here?

pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=8dca3c72221a

Try run for 8dca3c72221a is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=8dca3c72221a Results (out of 67 total builds): success: 67 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jhammel@mozilla.com-8dca3c72221a

pushed: http://hg.mozilla.org/build/talos/rev/38609147b9db

Sorry, I didn't mean to close until I got more to the heart of this issue. Muscle memory...

So with this additional debugging I can see the following: 09:26:38 INFO - Exception in writing file '' from results_url: file://C:\Us ers\jhammel\mozharness\src\mozharness\build\jetperf.txt not sure why we can't parse the bloody file out of there.

a permissions issue maybe? I am able to write results_url results to file:// locations on windows 7.

No, its a parsing error, as we're not getting back for the path segment what we would think. Will debug

>>> import urlparse >>> results_url = 'file://C:\Users\jhammel\mozharness\src\mozharness\build\jetpe rf.txt' >>> results_url_split = urlparse.urlsplit(results_url) >>> results_url_split SplitResult(scheme='file', netloc='C:\\Users\\jhammel\\mozharness\\src\\mozharne ss\x08uild\\jetperf.txt', path='', query='', fragment='') So apparently windows paths aren't parsed the same as unix paths o_O . Though now that I say that it does sound strikingly familiar. In unix, the path goes in the (you guessed it) 'path' part of the segment just as God Intended. :jmaher do you recall how you were able to avoid this error? Sadly, I think the solution is to parse our own damn file:// urls. This sounds like a job for mozfile.

Now I don't even get that far: C:\Users\jhammel\talos>Scripts\activate.bat (talos) C:\Users\jhammel\talos>talos -n -d -a ts -e "c:\Program Files (x86)\Mozi lla Firefox\firefox.exe" --develop --datazilla-url file://c:\Users\jhammel\foo.t xt setting debug DEBUG: using testdate: 1348612496 DEBUG: actual date: 1348612496 RETURN:<a href = "http://hg.mozilla.org/releases/mozilla-release/rev/0b774a1067f e">rev:0b774a1067fe</a> qm-pxp01: Started Tue, 25 Sep 2012 15:34:56 Running test ts: Started Tue, 25 Sep 2012 15:34:56 DEBUG: operating with platform_type : w7_ DEBUG: created profile Screen width/height:1600/900 colorDepth:24 Browser inner width/height: 1010/675 browser_name:Firefox browser_version:15.0.1 buildID:20120905151427 DEBUG: initialized firefox.exe DEBUG: command line: '"c:\Program Files (x86)\Mozilla Firefox\firefox.exe" -pro file c:\\\users\\\jhammel\\\appdata\\\local\\\temp\\\tmp0r5hy1\\\profile http:// localhost:15707/startup_test/startup_test.html?begin=' DEBUG: unknown error during cleanup Traceback (most recent call last): File "C:\Users\jhammel\talos\Scripts\talos-script.py", line 8, in <module> load_entry_point('talos==0.0', 'console_scripts', 'talos')() File "C:\Users\jhammel\talos\talos\run_tests.py", line 295, in main run_tests(parser) File "C:\Users\jhammel\talos\talos\run_tests.py", line 250, in run_tests talos_results.add(mytest.runTest(browser_config, test)) File "C:\Users\jhammel\talos\talos\ttest.py", line 417, in runTest self.cleanupProfile(temp_dir) File "C:\Users\jhammel\talos\talos\ttest.py", line 147, in cleanupProfile self._hostproc.removeDirectory(dir) File "C:\Users\jhammel\talos\talos\ffprocess.py", line 142, in removeDirectory shutil.rmtree(dir) File "C:\Python27\Lib\shutil.py", line 245, in rmtree rmtree(fullname, ignore_errors, onerror) File "C:\Python27\Lib\shutil.py", line 245, in rmtree rmtree(fullname, ignore_errors, onerror) File "C:\Python27\Lib\shutil.py", line 250, in rmtree onerror(os.remove, fullname, sys.exc_info()) File "C:\Python27\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\\jhammel\\appdata\\local\\temp\\tmp0r5hy1\\p rofile\\Cache\\_CACHE_001_' (talos) C:\Users\jhammel\talos>

In the above case, the browser never closed. Not sure why this is. Worth making sure the startup test works at all on windows

Confirmed that I can in fact run tsvg now. If it ain't one thing, its another thing

(In reply to Jeff Hammel [:jhammel] from comment #13) > In the above case, the browser never closed. Not sure why this is. Worth > making sure the startup test works at all on windows This is actually bug 794678 and unrelated to this bug.

This now works