Reland of Linux: Disable DBus auto-launch

Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when setting Envvars (in this case, appending to the python path to start a websocket server). The race appeared immediately after this patch landed, so it may be legitimate. Reverting this to see if it clears the failures up; if so, we'll probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658, 695643, 713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed: https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd13b6c61681b0

> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed: https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc4fb4510ce173

BUG=715658, 695643, 713947, 719633
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org

Review-Url: https://codereview.chromium.org/2865283002
Cr-Commit-Position: refs/heads/master@{#470301}
Committed: https://chromium.googlesource.com/chromium/src/+/2fc330d0b93d4bfd7bd04b9fdd3102e529901f91

[Primiano Tucci (use gerrit), 2017-05-09 10:58:01]

Created Reland of Linux: Disable DBus auto-launch

[Primiano Tucci (use gerrit), 2017-05-09 10:58:21]

Description was changed from

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for revert:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=715658,695643,713947
==========

to

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for revert:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
==========

[Primiano Tucci (use gerrit), 2017-05-09 11:05:05]

Description was changed from

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for revert:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
==========

to

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
==========

[Primiano Tucci (use gerrit), 2017-05-09 11:19:13]

primiano@chromium.org changed reviewers:
+ glider@chromium.org
- iclelland@chromium.org, jam@chromium.org, satorux@chromium.org,
satorux@google.com, thestig@chromium.org

[Primiano Tucci (use gerrit), 2017-05-09 11:19:13]

+glider for the new suppression
TBR-ing others as this is a reland as-is

[_com_google_glider, 2017-05-09 11:23:04]

On 2017/05/09 11:19:13, Primiano Tucci wrote:
> +glider for the new suppression
> TBR-ing others as this is a reland as-is

LGTM

[Primiano Tucci (use gerrit), 2017-05-09 11:24:46]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2017-05-09 11:25:17]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-09 11:25:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-09 11:25:19]

No L-G-T-M from a valid reviewer yet.
CQ run can only be started once the patch has received an L-G-T-M from a full
committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,_not_ a
full super star committer.
Committers are members of the group "project-chromium-committers".
Note that this has nothing to do with OWNERS files.

[Primiano Tucci (use gerrit), 2017-05-09 11:33:41]

Description was changed from

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
==========

to

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org
==========

[Primiano Tucci (use gerrit), 2017-05-09 11:34:06]

Description was changed from

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...
> 
>
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org,satorux@chromium...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=715658,695643,713947
> 
> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org
==========

to

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...

> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org
==========

[Primiano Tucci (use gerrit), 2017-05-09 11:34:12]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2017-05-09 11:34:31]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-09 13:07:17]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1494329652380830,
"parent_rev": "94910a8559c84218fcb67da99cd6365021fd8a67", "commit_rev":
"2fc330d0b93d4bfd7bd04b9fdd3102e529901f91"}

[commit-bot: I haz the power, 2017-05-09 13:07:29]

Description was changed from

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...

> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org
==========

to

==========
Reland of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2869843003/ )

Reason for reland:
Adding TSan suppression. The race is independent of this CL, see
crbug.com/719633


Original issue's description:
> Revert of Linux: Disable DBus auto-launch (patchset #1 id:1 of
https://codereview.chromium.org/2861163002/ )
> 
> Reason for revert:
> Speculative revert -- the TSan bots have been reporting a data race when
setting Envvars (in this case, appending to the python path to start a websocket
server). The race appeared immediately after this patch landed, so it may be
legitimate. Reverting this to see if it clears the failures up; if so, we'll
probably just have to serialize the calls to setenv.
> 
> Filed crbug.com/719633 for this as well.
> 
> Original issue's description:
> > Linux: Disable DBus auto-launch
> > 
> > This is a workaround (ETA ~ 2-3 years) for libdbus not being multi-threading
> > friendly and causing random hangs when running chrome outside of Linux
> > desktop environments.
> > 
> > Background:
> > -----------
> > Typically, Linux desktop environments set the DBUS_SESSION_BUS_ADDRESS
> > environment variable. This variable allows the dbus client library to
> > directly connect to the existing bus, which is started by the desktop
> > environment or systemd.
> > When this variable is missing, the dbus client library will fallback
> > to auto-launch mode [1], which causes 4 nested fork() + exec() calls.
> > Doing this has two problems: (i) slows down startup; (ii) can hang
> > the browser if the fork() happens while another thread is in a malloc()
> > (Chrome's tcmalloc has no at-fork handlers).
> > This situation (no env variable) is very common in test scenarios
> > (browsertests, chromedriver, etc).
> > 
> > Change introduced by this CL:
> > -----------------------------
> > This CL sets the bus address env variable to "disabled:" if not set.
> > This effectively shuts down the dbus auto-launch. If necessary, this
> > behavior can be restored by setting, before launching chrome,
> > DBUS_SESSION_BUS_ADDRESS="autolaunch:" .
> > This workaround will be necessary until libdbus and gspawn are fixed
> > to be multi-threading friendly [2,3] and that fix rolls into the
> > various distributions.
> > The change is introduced in the main embedder rather than in the
> > google-chrome wrapper, as several binaries can be affected by this,
> > for instance:
> > - browser tests (http://crbug.com/693668)
> > - chrome --headless
> > - webdriver/selenium which seem to directly invoke "chrome"
> >    see https://github.com/SeleniumHQ/docker-selenium/issues/87
> > 
> > [1] https://dbus.freedesktop.org/doc/dbus-launch.1.html
> > [2] https://bugs.freedesktop.org/show_bug.cgi?id=100843
> > [3] https://bugs.chromium.org/p/chromedriver/issues/detail?id=1699
> > 
> > BUG=715658,695643,713947
> > TEST=strace -ff -o trace chrome; grep dbus-launch trace*
> > 
> > Review-Url: https://codereview.chromium.org/2861163002
> > Cr-Commit-Position: refs/heads/master@{#469987}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/8511820ec8280caacbd4f81f3ecd...

> Review-Url: https://codereview.chromium.org/2869843003
> Cr-Commit-Position: refs/heads/master@{#470059}
> Committed:
https://chromium.googlesource.com/chromium/src/+/1e78cb7863da28bb3411286cdbcc...

BUG=715658,695643,713947,719633
TBR=satorux@google.com,thestig@chromium.org,jam@chromium.org

Review-Url: https://codereview.chromium.org/2865283002
Cr-Commit-Position: refs/heads/master@{#470301}
Committed:
https://chromium.googlesource.com/chromium/src/+/2fc330d0b93d4bfd7bd04b9fdd31...
==========

[commit-bot: I haz the power, 2017-05-09 13:07:30]

Committed patchset #2 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/2fc330d0b93d4bfd7bd04b9fdd31...