Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try setting DBUS_SESSION_BUS_ADDRESS when running tests in Chromedriver #5626

Merged
merged 2 commits into from
Apr 21, 2017

Conversation

jgraham
Copy link
Contributor

@jgraham jgraham commented Apr 20, 2017

This change is Reviewable

@w3c-bots
Copy link

w3c-bots commented Apr 20, 2017

View the complete job log.

Lint

Passed

@w3c-bots
Copy link

w3c-bots commented Apr 20, 2017

View the complete job log.

Firefox (nightly channel)

Testing web-platform-tests at revision 2d52816
Using browser at version BuildID 20170420100256; SourceStamp 27311156637f9b5d4504373967e01c4241902ae7
Starting 10 test iterations
No tests run.

@w3c-bots
Copy link

w3c-bots commented Apr 20, 2017

View the complete job log.

Chrome (unstable channel)

Testing web-platform-tests at revision 2d52816
Using browser at version 59.0.3071.15 dev
Starting 10 test iterations
No tests run.

@codecov-io
Copy link

codecov-io commented Apr 20, 2017

Codecov Report

Merging #5626 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #5626   +/-   ##
=======================================
  Coverage   87.22%   87.22%           
=======================================
  Files          24       24           
  Lines        2418     2418           
  Branches      406      406           
=======================================
  Hits         2109     2109           
  Misses        239      239           
  Partials       70       70

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a741b1e...f7f7921. Read the comment docs.

@jugglinmike
Copy link
Contributor

(This workaround is currently being discussed in gh-5406.)

@jugglinmike
Copy link
Contributor

After (finally) reproducing the issue locally and verifying the efficacy of the workaround, and after reading the sordid history of the problem from ChromeDriver to Chromium to glib, I'm starting to come around to this.

From a purely technical perspective: it seems a little imprecise to incorporate the workaround into the "check stability" utility directly. We now know that the problem is limited to non-interactive environments. Did you consider implementing this as part of the TravisCI test script?

Copy link
Contributor

@jugglinmike jugglinmike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On IRC, we discussed implementing this workaround in wptrunner. I'm not sure if that's still on your radar, but even if this is just an "interim" fix, I'd like to see a little more formal structure. Nothing major, though!

@@ -172,6 +172,9 @@ def version(self):
def wptrunner_args(self):
return NotImplemented

def extra_setup(self):
pass
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The term "setup" is a bit ambiguous in this context (i.e. more installation
steps?) Could we rename the extra_setup method to prepare_environment? And
defer its invocation to just prior to run_tests?

Also, could you add a doc string?

def extra_setup(self):
# https://bugs.chromium.org/p/chromium/issues/detail?id=713947
logger.debug("DBUS_SESSION_BUS_ADDRESS %s" % os.environ.get("DBUS_SESSION_BUS_ADDRESS"))
if "DBUS_SESSION_BUS_ADDRESS" not in os.environ:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only necessary in Linux; could we bail in other environments?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that necessary given that there are no other environements at the moment and everything will certainly break in !linux, given that we are downloading linux-specific binaries?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I guess I forgot that context. Adding the condition now would make future efforts towards portability easier, but that would be a big job anyway (and one I don't know if we're even considering). I'm fine with leaving it as-is

logger.debug(subprocess.check_output(["dbus-launch"]))
else:
logger.debug("Setting DBUS_SESSION_BUS_ADDRESS to a placeholder value")
os.environ["DBUS_SESSION_BUS_ADDRESS"] = "/dev/null"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't currently understand the implications of using this value. I am going to take some time to learn what this actually means.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we believe that this works and dbus-launch also seems to work in the travis environment can we land this whilst you do that research? As I say at some point I will move this into wptrunner and we can be more careful then.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My research is complete. The short version: let's fail the build instead of setting the variable to /dev/null.

The manual page for dbus-launch reads:

If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use
D-Bus, by default the process will attempt to invoke dbus-launch with the
--autolaunch option to start up a new session bus or find the existing bus
address on the X display or in a file in ~/.dbus/session-bus/

Which means that setting the variable to any value will have the intended result: stopping glib from attempting to start a session. However, setting it to /dev/null will effect the way Chrome interacts with the system. This is unlikely to be a problem today, but I'm concerned about future scenarios where tests are being written for the Web Bluetooth API (for example). I'd hate to trip anyone up just because they assumed that this low-level integration was valid.

The threat may seem kind of protracted, but I think it's fair to be conservative (call it paranoid if you like) here. That's because in reality, we have no use-case for this branch. The latest job log demonstrates that TravisCI (i.e. the only environment that requires this workaround) offers the dbus-launch executable:

DEBUG:check_stability:DBUS_SESSION_BUS_ADDRESS None
DEBUG:check_stability:Attempting to start dbus
DEBUG:check_stability:DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-R7UYTMZ60G,guid=5b04beaf64b61ac2fe15c33858fa3141
DBUS_SESSION_BUS_PID=5839
DBUS_SESSION_BUS_WINDOWID=2097153

So the branch in question effectively states: "Do something potentially invalid in a case that we don't currently need to support." We could just remove that branch, but I think it would be more responsible to report a meaningful error for this case, just in case this script winds up getting ported to some new environment (FreeBSD on Docker...?). Something like, "Due to a bug in glib, a valid DBUS session address must be defined before starting Chrome."

In effect, the current branch silently implements a workaround for that future case, but it's a workaround that might have deeper ramifications. Reporting an error would give the future caller the knowledge they need to implement a version of this workaround that is suited to their environment (even including DBUS_SESSION_BUS_ADDRESS=/dev/null).

@jgraham jgraham force-pushed the chrome_dbus_environ branch 2 times, most recently from 2e8864c to fe6eb9a Compare April 21, 2017 16:53
Copy link
Contributor

@jugglinmike jugglinmike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. I don't know how you want to merge this (or if you'd like me to do it), but note that the commit message should be updated as well ("set the relevant environment variable to a bogus value.")

Due to a bug in glibc Chrome may hang when dbus isn't
started (c.f. https://crbug.com/713947). This is not usually the case
on machines being used interactively but is the case on Travis and
other CI environments. As a workaround try starting dbus, and error
out if that fails.
@jgraham jgraham merged commit cd80437 into master Apr 21, 2017
@plehegar plehegar deleted the chrome_dbus_environ branch September 25, 2017 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants