By setting XDG_CACHE_HOME to self._port.results_directory() will make the worker reuse the cache of some previous and potentially taint the results. It should be set to the work's temporary directory instead, which is removed after the run. Currently the Application Cache is the only to respect this environment variable on WebKit2 because there is no API to override the path like it is usually done on DRT and WTR.
Created attachment 171671 [details] Patch
Comment on attachment 171671 [details] Patch Clearing flags on attachment: 171671 Committed r133050: <http://trac.webkit.org/changeset/133050>
All reviewed patches have been landed. Closing bug.
This change seems to be causing failures in the chromium port's webkitpy-test; e.g., see http://build.webkit.org/builders/Chromium%20Win%20Release%20%28Tests%29/builds/31058/steps/webkitpy-test/logs/stdio "Seems" because it's the only xvfb-related change in the first failing run: http://build.webkit.org/builders/Chromium%20Win%20Release%20%28Tests%29/builds/31058
(In reply to comment #4) > This change seems to be causing failures in the chromium port's webkitpy-test; e.g., see > > http://build.webkit.org/builders/Chromium%20Win%20Release%20%28Tests%29/builds/31058/steps/webkitpy-test/logs/stdio > > "Seems" because it's the only xvfb-related change in the first failing run: > > http://build.webkit.org/builders/Chromium%20Win%20Release%20%28Tests%29/builds/31058 Hmmm, weird. The patch just changes a environment variable path. Is the Windows bot really suppose to start the Xvfb server?
> Is the Windows bot really suppose to start the Xvfb server? It looks like something isn't properly mocking out the file system.
It's also possible we should skip this test on Windows.