New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 607313 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

[Windows Host] Windows host cannot accept new connections

Project Member Reported by joedow@chromium.org, Apr 27 2016

Issue description

A recent change to some IPC code seems to have broken the Chromoting Host's ability to establish new connections.

I've rolled back the following change and CRD works grea, re-applying break us again:
9097190cafdecfb1b5796b65c83af92e861ccaf8
https://codereview.chromium.org/1903663004/
 

Comment 1 by joedow@chromium.org, Apr 27 2016

Components: Services>Chromoting
Labels: OS-Windows
Owner: joedow@chromium.org

Comment 2 by joedow@chromium.org, Apr 28 2016

Status: Started (was: Assigned)
Project Member

Comment 3 by bugdroid1@chromium.org, Apr 29 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3d4a0c92b0079c32e777933a52b6d8eaf32d0c6e

commit 3d4a0c92b0079c32e777933a52b6d8eaf32d0c6e
Author: joedow <joedow@chromium.org>
Date: Fri Apr 29 15:18:51 2016

Fixing an AttachmentBroker problem which broke the windows host

A previous change did some cleanup in the remoting codebase however it caused
a crash when we tried to spin up the desktop process:
https://codereview.chromium.org/1903663004/

The issue was that the code in the ipc_utils_win file attempted to register a
broker but did not check to see if one was registered first.  The
DesktopProcess class did register a broker, but did so after this utility
function was called.

BUG= 607313 

Review-Url: https://codereview.chromium.org/1925263002
Cr-Commit-Position: refs/heads/master@{#390653}

[modify] https://crrev.com/3d4a0c92b0079c32e777933a52b6d8eaf32d0c6e/remoting/host/desktop_process.cc
[modify] https://crrev.com/3d4a0c92b0079c32e777933a52b6d8eaf32d0c6e/remoting/host/ipc_util_win.cc
[modify] https://crrev.com/3d4a0c92b0079c32e777933a52b6d8eaf32d0c6e/remoting/host/remoting_me2me_host.cc
[modify] https://crrev.com/3d4a0c92b0079c32e777933a52b6d8eaf32d0c6e/remoting/host/win/wts_session_process_delegate.cc

Comment 4 by joedow@chromium.org, Apr 29 2016

Owner: mmeade@chromium.org
Status: Fixed (was: Started)

Comment 5 by joedow@chromium.org, Apr 29 2016

Owner: ajnolley@chromium.org
Thanks, can you merge this to M51?

Comment 7 by joedow@chromium.org, Apr 29 2016

I discussed this with our release manager yesterday and decided not to merge it yet.

We've already snapped our release (for the CRD host for M51) and don't plan on taking any additional changes so I don't think this needs to be merged since it only touches CRD code.  If we do decide we need to produce another release candidate, I will merge the change in.
Cc: erikc...@chromium.org
Ah, I see. So you're saying that my change that I merged to M51 won't affect CRD, and therefore your CL also does not need to be merged?

Comment 9 by joedow@chromium.org, Apr 29 2016

We snapped our CRD release prior to your merge so the host we plan to release is working fine.  If we need to update our release candidate from M51, then I will merge my change in.
Status: WontFix (was: Fixed)
Marking as Won'tFix for now. If we release another M51 Host, I will reopen
Owner: joedow@chromium.org
Status: Assigned (was: WontFix)
Joe, did this make it into M52? I am unable to connect to any M52 Host (quick white screen, then a disconnect, same as M51 Hosts after our release)
Owner: ajnolley@chromium.org
Status: Fixed (was: Assigned)
I'm pretty sure this specific issue is fixed, can you open a new bug and include host logs ?
Status: Verified (was: Fixed)
Verified Fixed in 52.0.2743.33

Sign in to add a comment