New Project problem - dialog to create new project is not appearing

[alcar]

RStudio: 1.1.463
R version: 3.5.2
OS: Windows 10 Pro

Something has go wrong with my RStudio installation.

The problem I will discuss here is creating a New Project.

Steps Taken:

1. Start RStudio
2. Click File -> New Project

Expected Result: Opens New Project Dialog where I get to select the type and location of the new project

Failing Result: nothing happens at all; no dialog or other response from RStudio

Attempted Fixes: (all failed)

• Deleting .RData from home directory in case it is loading something bad
• Browsing to an empty directory and setting that as the working directory
• Uninstalling and reinstalling RStudio
• Uninstalling and reinstalling R and RTools
• Uninstalling Microsoft Visual Studio R support
• Ensuring nothing else is running that isn't essential

As mentioned a few other things appear to be going wrong and I have been forced to use Task Manager to kill the RStudio processes a number of times when it goes into a guru mediation.

Here are a few other problems in no particular order:
(these are can maybe related to the main issue)

• When quitting RStudio the message "Quitting R Session..." appears and it goes into a guru mediation eventually requiring killing the process
• Clicking on "Packages" tabs also sometimes results in meditative behaviour (I'm using the Australian CSIRO CRAN mirror which is just down the road from me)
• Setting "Default working Directory (....):" in Global Options does not do anything. It still opens in my Windows home directory
• Entering in the console library(devetools) just now resulted in sitting there doing nothing

All the above was done immediately after opening a new session and waiting a respectable amount of time for RStudio to feel good and comfortable.

When meditating RStudio is thinking very deep thoughts using lots of CPU cycles.

.... still thinking about what to do with library(devtools) after about a few minutes ... will give it a little longer

[alcar]

I just tried a complete uninstall of RStudio, RTools, and R the rebooted my computer from scratch.

This did not correct the problem. Are there any settings that may be left behind which I should delete?

I noticed that after doing the full uninstall, reboot, and reinstall, RStudio seems to have some knowledge of my previous configuration.

Is there anything left in the Windows Registry that I should remove?

Another problem has emerged, maybe related.
I can no longer open the "Tools" -> "Global Options..." dialog.

Does anyone have a windows script to completely wipe all R and RStudio configuration from the computer? One that assumes the user does not want to keep any personalised settings

• I delete the directory "C:\Users\Alan\AppData\Local\RStudio-Desktop" after uninstalling
• I manually cleaned out all references to RStudio in the regisary
• Made sure that both 32 and 64 bit versions of R and RTools are installed in case RStudio uses both

I noticed that after choosing "Create a Project" toolbar icon or "New Project..." an instance of make.exe building a 64 bit object file starts to use run using a lot of CPU cycles. This runs for a long time... actually it still hasn't stopped after 5 minutes.

[Yarnabrina]

I'm not sure, but you can try deleting the folder containing the downloaded R packages (by default in the location C:\Users\Username\R) and the folder containing temporary files (by default in the location C:\Users\Username\AppData\Local\RStudio-Desktop).

(By by default, I meant the locations in my device, and I'm sure that I accepted all the defaults while installing R, RStudio and Rtools)

[alcar]

Thanks @Yarnabrina,

I tried deleting RStudio-Desktop and am now trying deleting the R user packages directory. (On my machine this is in C:\Users%USERNAME%\Documents\R)

Partial Spanner Whack Fix

I just discovered that killing the make.exe process that starts when I try to create a new project lets the dialog open straight away. It is this process that seems to be blocking things.
I switched between using 32 and 64 bit version of R (using global options) and the same happens when make.exe runs.

What is this process doing?
A screen shot of the command line for it from Task Manager is attached.

R%20Make%20Processes|690x40

[Yarnabrina]

@alcar

R%20Make%20Processes|690x40

Well, I cannot open this screenshot. Usually, the pictures are shown, and this one is displayed as a link, clicking which results in nothing. Can you check this?

I just tried to create a new project, which took just a second or two, comparing with your case of more than 5 minutes. So I'm wondering whether you did the following:

1. uninstalled R, RStudio and Rtools
2. cleared temporary files and installed packages
3. reinstalled everything

After these, you tried to create a project and failed. Is that the case?

[alcar]

Yes that's what's been happening.
I've done this a couple of times now. I sill need to do a full reinstall after deleting the R directory you suggested.

Dragged and dropped the picture maybe this will work.

[Yarnabrina]

@alcar

I sill need to do a full reinstall after deleting the R directory you suggested.

Well, if this doesn't work, I'm out of all ideas, being not quite familiar with rstudio projects myself.

Hopefully, someone else with be able to resolve your issue.

[alcar]

Thanks @Yarnabrina

Killing that make.exe seems to give me some ability to create new projects and do other things. But I don't know what possible consequence this might have.

It definitely seems to be a problem with the make.exe and subsequent compile and linking getting a stuck. It seems to be running using about quarter of CPU capacity.

Right now I am installing tidyverse and a package needs building so make is once again very busy.

The RStudio console command being executed is

* installing *source* package 'stringi' ...
** package 'stringi' successfully unpacked and MD5 sums checked
** libs

*** arch - i386
C:/Rtools/mingw_32/bin/g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-35~1.2/include" -DNDEBUG -I. -Iicu61/ -Iicu61/unicode -Iicu61/common -Iicu61/i18n -DU_STATIC_IMPLEMENTATION -DU_COMMON_IMPLEMENTATION -DU_I18N_IMPLEMENTATION -DUCONFIG_USE_LOCAL -DU_TOOLUTIL_IMPLEMENTATION -DNDEBUG -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DU_USE_STRTOD_L=0         -O2 -Wall  -mtune=generic -c stri_pad.cpp -o stri_pad.o

I might give Microsoft Visual Studio R a go and see if this works for me. Would prefer RStudio though as everyone else is using it.

[kevinushey]

Do you have any better luck with the preview release?

Is it possible that R / RStudio is attempting to automagically download and install packages from source in your project when you're opening it? That could be a potential explanation for the busy make executable (which is used by R during package installation from source)

It's also worth asking what the output of Sys.which("make") is, in case R / RStudio is inadvertently finding and using an incompatible version of make.

[alcar]

Thanks @kevinushey preview release.

Before I do that here's a bit more I found out after further investigation.

First off Sys,which("make") return the C:\Rtools\bin\make.exe

I execute the make.exe on the command-line with debugging option (had to track down the temp c file used first). Doing this resulted in the following error when gcc.exe attempts to link.

c:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o test3b2c452c4eee.dll tmp.def test3b2c452c4eee.o -L/bin/x64 -lR C:/Rtools/mingw_64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lR collect2.exe: error: ld returned 1 exit status

If I take the gcc command and execute it with the -lR removed from the end it seems to work okay resulting in the windows DLL being created.

I'm guessing, given where it appears in the gcc call, -lR is meant to be -LR so any R directory is included in the libraries search. Change it accordingly and it completes building the DLL.
This is about as far as I got with this and suspect that none of this is actually relevant to why make.exe just sits there consuming CPU and getting nowhere.

Will try the preview version and just keep kill make.exe when it misbehaves.

[alcar]

Update to last post

Just tried the idea in my last post again; manually coping the test????.c file to another directory and executing the make.exe without any modification and it seemed to work as expected. Regardless of the -lR option or existence of an R directory or file. (I am assuming -lR is passed to the linker ld.exe as option -l LIBNAME.)

The make.exe once again consumed 25% of CPU and failed to complete.

As I suspected this was not the source of the problem. I have no idea why it failed yesterday and completed today. Or why this problem is happening at all.

[alcar]

Just tried this with RStudio v1.2.1293-1 Preview and the problem still exists.

1. Click File -> New Project...
2. RStudio is now stuck and unresponsive
3. Task Manager shows make.exe using CPU 25 (about standard operating load for GNU tools)
4. Go for a walk, get a coffee, read a news paper, come back a while later, and make.exe is still chugging away doing its thing.

Tried everything up-to and including complete uninstallation of all R software, other embedded MSYS or MingW deployments, registry and file system cleansing, etc.

[kevinushey]

I believe the code that is attempting to run here is from https://github.com/rstudio/rstudio/blob/master/src/cpp/session/modules/build/SessionBuild.cpp#L2226. In effect, we're trying to run:

R CMD SHLIB test.c

and checking whether that attempt to compile by R succeeds. What happens if you try to run

writeLines("void test() {}", con = "test.c")
R <- file.path(R.home("bin"), "Rcmd.exe")
system(paste(normalizePath(R), "SHLIB test.c"))

For example, I get:

> writeLines("void test() {}", con = "test.c")
> R <- file.path(R.home("bin"), "Rcmd.exe")
> system(paste(normalizePath(R), "SHLIB test.c"))
c:/Rtools/mingw_64/bin/gcc  -I"C:/R/R-35~1.2/include" -DNDEBUG     -I"C:/RBuildTools/extsoft/include"     -O2 -Wall  -std=gnu99 -mtune=generic -c test.c -o test.o
c:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o test.dll tmp.def test.o -LC:/RBuildTools/extsoft/lib/x64 -LC:/RBuildTools/extsoft/lib -LC:/R/R-35~1.2/bin/x64 -lR

Have you done anything to modify e.g. the R installation's etc/Makeconf file, or a local Makevars file, or anything similar? Are there any utilities on the PATH that could be causing trouble? (Note that Rtools itself normally needs to be first on the PATH during compilation)