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

Intermittent error connecting to R on desktop build #8270

Closed
jmcphers opened this issue Nov 2, 2020 · 31 comments · Fixed by #8382, #8554 or #8614
Closed

Intermittent error connecting to R on desktop build #8270

jmcphers opened this issue Nov 2, 2020 · 31 comments · Fixed by #8382, #8554 or #8614
Assignees
Labels
bug desktop integration Desktop shell and OS integration; file associations, icons, etc.
Milestone

Comments

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Nov 2, 2020

System details

RStudio Edition : Desktop
RStudio Version : 1.4.998
OS Version      : Unknown

Steps to reproduce the problem

Unknown, but for affected users it happens intermittently when starting RStudio.

Describe the problem in detail

image

Retrying usually addresses the problem as per @hadley.

Describe the behavior you expected

RStudio should be able to connect to R. We do see intermittent failures from time to time, but this one warrants further investigation since:

  • it has been reported by both @hadley and @mine-cetinkaya-rundel
  • it started happening for both of them at nearly the same time
  • we changed the code that shows this page very recently in PR #8148.
@jmcphers jmcphers added the desktop integration Desktop shell and OS integration; file associations, icons, etc. label Nov 2, 2020
@jmcphers jmcphers added this to the v1.4 milestone Nov 2, 2020
@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Nov 4, 2020

Do we have a way to reliably reproduce this?

@MariaSemple
Copy link
Collaborator

@MariaSemple MariaSemple commented Nov 5, 2020

I have been trying to reproduce, but haven't been able to yet.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Nov 5, 2020

I also haven't been able to reproduce. I think we'll have to audit the ways in which the error page can be triggered, and think about poking at the problem from ways that could manifest.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Nov 6, 2020

Some thoughts on how we could approach this...

One hypothesis is that we're getting the wrong return value here:

void MainWindow::onLoadFinished(bool ok)
{
LOCK_MUTEX(mutex_)
{
if (ok || pRemoteSessionLauncher_ || isErrorDisplayed_)
return;
RS_CALL_ONCE();
std::map<std::string,std::string> vars;
vars["url"] = webView()->url().url().toStdString();
std::ostringstream oss;
Error error = text::renderTemplate(options().resourcesPath().completePath("html/connect.html"),
vars, oss);
if (error)
LOG_ERROR(error);
else
loadHtml(QString::fromStdString(oss.str()));
}
END_LOCK_MUTEX
}

We could ignore the value of ok (perhaps it's incorrect some percentage of the time?) and instead check and see if we can evaluate a JavaScript callback on the window that would indicate if the load was successful.

Another hypothesis is that we're getting multiple loadFinished() signals -- https://bugreports.qt.io/browse/QTBUG-87089 suggests this is at least possible. If that's the case, then we could even delay the error check here (on a timer) just in case we're getting a premature loadFinished() response with the wrong result.

I'm not able to see how #8148 could affect this outcome, though...

@MariaSemple
Copy link
Collaborator

@MariaSemple MariaSemple commented Nov 6, 2020

Yes - the only thing I can't think is that the potential for this bug was there before #8148 but adding the mutex and additional boolean flag check somehow changed the timing so that the bug is getting triggered more often. We could also lock the mutex in the section of the code that decides whether the load was okay, so that it's not possible to both load the cannot connect page and have connected successfully.

@blairj09
Copy link

@blairj09 blairj09 commented Nov 9, 2020

I don't know if this could possibly have any impact, but I always open RStudio on a second monitor (my MacBook is always closed and I have it hooked to another monitor).

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Nov 12, 2020

I was able to reproduce locally, and it looks like loadFinished() is getting called multiple times. The first time it's called with false; then second time with true.

kevinushey@cdrv-2:~/rstudio-v14/src/build-cpp-Desktop_Qt_5_12_8_clang_64bit-RelWithDebInfo [master]
$ build && ./rstudio-dev
ninja: no work to do.
Loaded: false
Loaded: true

I don't know why this is the case, but I think the right resolution here is to use a timer and allow a small window where we wait to see if a "failed" window load is followed by a "successful" window load, and forego displaying the error message when that happens.

@blairj09
Copy link

@blairj09 blairj09 commented Nov 18, 2020

Noticed this doesn't manifest in daily 1.4.1038-2! Great work!

@kfeinauer
Copy link
Contributor

@kfeinauer kfeinauer commented Nov 18, 2020

Verified by community, and I also have not seen it lately.

@mine-cetinkaya-rundel
Copy link

@mine-cetinkaya-rundel mine-cetinkaya-rundel commented Nov 18, 2020

I'm still getting this intermittent error

RStudio Edition : Desktop
RStudio Version : 1.4.1043
OS Version      : macOS Catalina 10.15.7

@kevinushey kevinushey reopened this Nov 30, 2020
@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Nov 30, 2020

@hadley also reports seeing this in 1.4.1066.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Nov 30, 2020

@hadley mentions the issue is at least less frequent in 1.4; we might be able to get away by bumping up the timer delay on the PR in #8382.

@blairj09
Copy link

@blairj09 blairj09 commented Nov 30, 2020

This had resolved for me, but it appeared again today on RDP 1.4.1063-1

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 2, 2020

Should (hopefully) be fixed by #8499. Please let us know if you're still seeing this issue in the latest builds!

(If the issue still re-occurs, I think we should re-open and target for a future milestone as anything more invasive will be out of scope for 1.4)

@kfeinauer
Copy link
Contributor

@kfeinauer kfeinauer commented Dec 4, 2020

@mine-cetinkaya-rundel @blairj09 How is this looking on the latest daily? Improved, I hope?

@hadley
Copy link
Member

@hadley hadley commented Dec 4, 2020

It's no better for me on 1.4.1073

@mine-cetinkaya-rundel
Copy link

@mine-cetinkaya-rundel mine-cetinkaya-rundel commented Dec 4, 2020

Just tried it with 1.4.1078 and it's not better for me either

@kfeinauer kfeinauer reopened this Dec 4, 2020
@mine-cetinkaya-rundel
Copy link

@mine-cetinkaya-rundel mine-cetinkaya-rundel commented Dec 4, 2020

I don't know if this is helpful, but lately, I see the following first when I launch RStudio. This goes away after a few seconds and turns into the screen at the beginning of this issue.

Screenshot 2020-12-04 at 16 23 55

@jmcphers
Copy link
Member Author

@jmcphers jmcphers commented Dec 5, 2020

@mine-cetinkaya-rundel Thank you, this is extremely helpful. Does clicking Reload (during the several seconds in which this screen is displayed) fix the problem?

@kevinushey Maybe what's needed here is not waiting for a successful load to arrive (it seems like it never does in the most recent reports) but to do an automatic retry a limited number of times, perhaps separated by a short delay. What do you think?

@mine-cetinkaya-rundel
Copy link

@mine-cetinkaya-rundel mine-cetinkaya-rundel commented Dec 5, 2020

@jmcphers Yes, if I click reload it fixes the problem!

@mine-cetinkaya-rundel
Copy link

@mine-cetinkaya-rundel mine-cetinkaya-rundel commented Dec 11, 2020

With 1.4.1087, I'm seeing that intermittently upon launch RStudio gets stuck on the "This site can't be reached 127.0.0.1 refused to connect" screen, but this time with beach ball spinning so I can't click on Reload and it doesn't go away on its own. Force quitting and relaunching the project usually works.

@blairj09
Copy link

@blairj09 blairj09 commented Dec 11, 2020

I see new behavior with RStudio Desktop Pro 1.4.1087.5 running on macOS 11.0.1

  1. Download the latest daily (in this case 1.4.1087.5)
  2. Install the download by replacing the current version
  3. Open RStudio
  4. Accept the option to open it
  5. I see the same screen @mine-cetinkaya-rundel mentions
  6. I don't click Reload, I just wait
  7. Now, instead of seeing the second screen (which was the previous behavior) RStudio just hangs and never opens. I had to force quit the app and then open it again. When opening it again, it opened and behaved as expected.

@kfeinauer
Copy link
Contributor

@kfeinauer kfeinauer commented Dec 11, 2020

Not an ideal situation, but maybe @kevinushey could commandeer @blairj09's laptop for 20 minutes to debug what's going on so we can craft the correct fix.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 11, 2020

I've reverted 284c4b0 since it's evidently made the issue even worse. 😞

I'm going to spend some time seeing if I can properly reproduce the issue locally since I haven't been successful with speculative fixes thus far.

@blairj09
Copy link

@blairj09 blairj09 commented Dec 15, 2020

The behavior is gone for me with 1.4.1090-1! 🙌 I did see a brief "Connecting to R" screen, but I think that is probably expected. Great work!

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 15, 2020

Phew! Finally, that's fantastic news :)

@melissa-barca
Copy link
Contributor

@melissa-barca melissa-barca commented Dec 16, 2020

I'm marking this as Verified based on @blairj09's feedback 😄

@blairj09
Copy link

@blairj09 blairj09 commented Dec 16, 2020

Further verified with 1.4.1093-1. It seems the problem is fully resolved 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment