I'm running RStudio Preview 1.2.1114 (build 1150) on Windows 10 1809, and I'm having a problem where my notebook has started consistently becoming unresponsive when I try to add to it. If I save every few characters, I'm able to get a few more characters in, but then it stops responding. The behaviour involves:
I can add content to the notebook in the source pane, but I can't save the file or run chunks;
I can type out commands in the console, but when I hit Enter they don't run (and RStudio doesn't show a 'Stop' button as it would during lengthy calculations);
Submenu buttons work, but commands tied to buttons don't do anything;
I can type in boxes, like the documentation search, but pressing Enter doesn't do anything;
If I try to Exit , I'm prompted about unsaved changes, but if I press Save, the file isn't actually saved and the app doesn't quit (unless I force close it using the Task Manager).
In short, the interface isn't "frozen", but nothing relating to app state appears to work. CPU and RAM usage while in this state appears normal.
Not sure if this problem is specific to the contents of the notebook (I can attach it if necessary), but it's about about 80 lines with a couple of chunks plotting some basic data in ggplot2. I can no longer replicate the problem if I close the notebook, but when I created a test notebook, played around with it for two minutes, then closed it without saving and tried to create another one (thinking I would copy and paste my notebook into a new file), the IDE got stuck on "Creating new document..." and the interface become unresponsive in the same way.
EDIT: resource use with this crash when creating a new document looks a little different—it looks like Pandoc got hung up:
We've taken a new update of Pandoc on Windows and we're hopeful that this will resolve some of the issues seen with Pandoc hangs. (Note that if you're working with R Notebooks, then RStudio is rendering your notebook somewhat eagerly behind the scenes, and that implies invocations of Pandoc)
I'm experiencing this same issue. I updated to Version 1.2.1181 and it's still there... RStudio becomes unresponsive. I think it happens specifically when I save a notebook file.
If I go to the Task Manager and kill the pandoc process, it frees up RStudio.
Both my older WIndows 7 laptop at work and my brand-new Windows 10 home laptop exhibit the same issue. I have been installing a different daily build of Rstudio 1.2 preview every few days for the last couple weeks and always the same.
My hangup always exhibit the running Pandoc (32-bit) process consuming roughly 25% CPU (i.e. 100% of one logical core). If I kill that Pandoc process Rstudio becomes responsive again but will start running at 25% utilization again within a couple minutes (if not immediately).
No issues at all with Rstudio 1.1.463 so I continue to use that as my normal working environment. Fortunately for me I am just curious about the 1.2 preview and have no pressing need for any of the new functionality.
Sorry for the delay, @kevinushey! I've updated to v1.2.1194 and am getting similar problems. I opened up my notebook and couldn't run any chunks right off the bat. Trying to quit resulted in RStudio freezing, with 32-bit Pandoc chewing up a CPU core until I killed it (just as @BrentHutto is observing).
I'm having a little trouble replicating things consistently, though; other times I start RStudio up and chunks run and files save fine.
I'm also sometimes getting this error when I hit 'Restart R and Run All Chunks' (even if I haven't modified the notebook since the last successful run and all of the chunks actually do successfully run).
Error creating notebook: pandoc document conversion failed with error 1.
When I get this error, the following appears in my console following the final chunk: pandoc.exe: <<loop>>
Thanks! It looks like we're still having trouble with Pandoc; we're going to look into it (it appears we're still using a 32-bit binary but more success has been reported with the 64-bit binary)
Don't you changed to 32-bit version recently as a walk around solution for an error of pandoc 64-bit version on windows 10 systems? See this github issue
Right; we switched from the 32-bit version of Pandoc 2.3.1 to now the 64-bit version of Pandoc 2.5. Hopefully things will behave better with the latest version of Pandoc but please file a new issue if you have trouble.
Oh, wow, okay! So here's something puzzling: I've verified that my RStudio daily is running Pandoc 2.5 using rmarkdown::pandoc_available('2.5'), and Sys.getenv('RSTUDIO_PANDOC')returns C:/Program Files/RStudio/bin/pandoc, so I assume I'm running the 64-bit version of 2.5 that comes with this daily.
But when RStudio runs pandoc, in the Task Manager the task is labelled "pandoc.exe (32-bit)":
Upgraded from 1.2.1194 to 1.2.1206 and it looks like it's 64-bit now The Task Manager is showing the pandoc process when I knit as "pandoc.exe", not "pandoc.exe (32-bit)". I'm also, touch wood, not having any more problems with knitting or notebooks. I'll update if I run into any trouble! Thanks for your patience, Kevin!
The Pandoc hangs and "pandoc document conversion failed with error 1" issues I had experienced with all of the daily builds up through 1.2.1163 seem to have been resolved (touch wood).
I stuck to Rstudio 1.1 for a few weeks before downloading and installing the recent 1.2.1214 build. I've given it a fair workout while running and editing a fairly complex notebook and no crashes or issues of any kind, hooray! I even Knitted a couple of oddball document types (tufte_book, etc) that I never actually use, just to create maximum opportunities for problems to show up.
One curious thing, though. I watch my Windows Task Managers "Processes" view while running R and Knitting and I no longer see Pandoc.exe (either 32- or 64-bit) show up as a running process. That seems like new behavior in 1.2.1214, isn't it?
The Task Manager is showing the pandoc process when I knit as "pandoc.exe", not "pandoc.exe (32-bit)". I'm also, touch wood, not having any more problems with knitting or notebooks. I'll update if I run into any trouble! Thanks for your patience, Kevin!