[R-SIG-Mac] R GUI is freezing

Duncan Murdoch murdoch.duncan at gmail.com
Thu Feb 18 20:45:14 CET 2016


On 18/02/2016 2:18 PM, Vinny Mo wrote:
> I'll second Joe's report that opening almost any GUI (changing working directory from menu and use of "file.choose()" command) is still an issue for me. I'm using "Wooden Christmas Tree" on several different mac machines with small data sets, small scritps (less than 200 lines), using no outside packages, and still having consistent freezing issues.

Your report doesn't "second" his, yours is quite different.  He needed a 
long script and lots of memory allocations and rgl.  You apparently 
don't.  But like his report, you don't give us enough to go on.

You need to give version numbers, and an exact sequence of operations to 
reproduce the crash.  Then it'll likely be fixed.

Without knowing which version of R.app you were running ("Wooden 
Christmas Tree" is a version label on R, not R.app), on what version of 
Mac OS X, or what is necessary to duplicate the problem, we're unlikely 
to even try to fix it.

Duncan Murdoch
>
> Cheers,
>
> V
>
> ________________________________________
> From: R-SIG-Mac <r-sig-mac-bounces at r-project.org> on behalf of Duncan Murdoch <murdoch.duncan at gmail.com>
> Sent: Saturday, February 13, 2016 9:17 PM
> To: Joseph Kunkel
> Cc: r-sig-mac at r-project.org
> Subject: Re: [R-SIG-Mac] R GUI is freezing
>
> On 13/02/2016 1:42 PM, Joseph Kunkel wrote:
> > Sorry, but the freezing of the R-gui still persists:
> >
> > Previously I had downloaded the latest version of R from the CRAN directory for my Os X  MacBook Pro (Retina, 15-inch, Early 2013). The R-gui check on R upgrades suggested my R was up-to-date with no upgrades available.
> >
> > In that situation I experienced the R-gui freeze-up that I and others have alluded to before.
>
> You mention way down below that this only happens in very long running
> scripts using rgl and lots of memory.  I don't think that's typical of
> others with similar complaints.  I'd guess something in the mix isn't
> responding well to a memory allocation failure, but I really have no
> idea what it would be.
>
> I'd suggest running the whole thing in a debugger, and once the apparent
> lockup occurs, interrupt the process and see if you can figure out what
> is happening.  But it isn't going to be easy.
>
> The other suggestion would be to simplify things until you have less
> moving parts involved.  Does it need rgl?  Does it need the R.app GUI?
> Does it need whatever software you are using to produce movies?  Cut it
> down to a minimal reproducible example, and post that here.
>
> Duncan Murdoch
>
> >
> > On Duncans advice (Feb 11, 2 days ago) I tried the suggested nightly build and then ran one of my R scripts from the initial directory I had set in the R-gui preferences menu R-startup menu which was still the default det from the previous build.   R opened with the appropriately set working directory:
> >
> > R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree”
> > …
> > [R.app GUI 1.67 (7128) x86_64-apple-darwin13.4.0]
> >
> > I then ran a R-script to completion. … {I read somewhere that garbage collection is automatic and forcing it is only informational and does not improve a situation}. Despite that I have tried garbage collection.  ...  And I then tried to load another R-script into the editor from the same working directory.
> >
> > The R-gui froze with a rotating rainbow icon.
> >
> > I use my Terminal window to find and kill the R-process:
> >
> > Josephs-MacBook-Pro:~ josephgkunkel$ ps -x
> > ...
> > 6533 ??         9:44.90 /Applications/R.app/Contents/MacOS/R
> >
> > Josephs-MacBook-Pro:~ josephgkunkel$ kill 6533
> >
> > I then rebooted R:
> >
> > R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree”
> > …
> > [R.app GUI 1.67 (7128) x86_64-apple-darwin13.4.0]
> >
> > [Workspace restored from /Users/josephgkunkel/Documents/Analysis/AVI_M2C_0.5/spiral/spiral1a/.RData]
> > [History restored from /Users/josephgkunkel/Documents/Analysis/AVI_M2C_0.5/spiral/spiral1a/.Rapp.history]
> >
> > In addition the R-script that had been loaded into the editor at the freeze was auto-loaded.
> >
> > At this point I try to load the new R-script that I had wanted to load when the R-gui froze. ...
> >
> > The R-gui freezes again (because I did not close the opened R-script and close R and reopen it before trying to load the new R-script.
> >
> > {Something is wrong with the gui at this point!  Something, such as a log, saved prior to the R-gui freezing is now directing things.  Why else would a new reboot result in a freezup with a ordinary operation. }
> >
> > To run R successfully I must (1) re-kill the R process. (2) Boot the R-gui.  (3) Close any R-scripts that are brought up in the default editor. (4) Close the R-gui using the gui red-dot icon or q(). (5) Reboot the R-gui.
> >
> > When opened in this manner I can load several R-scripts into the editor but after running any substantial R-script I should not try to load another into the editor -or- change the working directory.
> >
> > I can run another R-script.
> >
> > QUESTION to Duncan:  Is the above reported R version and GUI version not yet the correct R-gui build?
> >
> > One clue?   After a freeze and reboot of R, the Rgui pulldown menu "File/Recent" initially shows "Clear Menu” rather than a list.   Retry still gives "Clear Menu”.
> >     After looking there repeatedly and getting "Clear Menu” and one 'goes somewhere else and does something else' and then comes back  to "File/Recent”, a list of appropriate old loads now appears ‘automagically’.  Then the loading of a new R-script works from this list ... but not via the “Open in Editor” icon.
> >
> > Another clue:  The R-scripts I run are often pretty heavy rgl library 3d function plotting programs that load v. large data sets and then in some cases create rotating movies that generate frames that are saved … the whole process taking up to an hour+.  Could this lead to 'memory leaks' that stomp on critical log files or parameters/variables that save critical info for process survival?  Occasinally the R process complains that I need to shut down non-essential processes that are using valuable memory.
> >
> > Shorter uses of rgl do not cause gui freezes however the protocol to recover from a gui freeze is still disconcertingly laborious.
> >
> > Joe
> >
> > -·.  .· ·.  .><((((º>·.  .· ·.  .><((((º>·.  .· ·.  .><((((º> .··.· >=-       =º}}}}}><
> > Joseph G. Kunkel, Research Professor
> > 112A Marine Science Center
> > University of New England
> > Biddeford ME 04005
> > http://www.bio.umass.edu/biology/kunkel/
> >
> >> On Feb 11, 2016, at 11:17 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> >>
> >> On 11/02/2016 10:50 AM, Joseph Kunkel wrote:
> >>> I have the same problem over many updates of R for my Mac.   After I load one R-script into the editor and run it, trying to open another script or trying to change my working directory results in R-gui freeze up.  In rebooting R I end up with the old R-script coming up in the editor and I must close it and close R once again before I can reboot R yet once again and start working bing aware that I must not try to open anothe R-scrip in the editor after a script has run or R-gui will lock up again.
> >>>
> >>> With respect to the suggestion to 'tr(Y) recent nightly builds from http://r.research.att.com/', it is the developer’s page and the link to the R-gui nightly build loops back to the same page with no clear option of how to load a new build of the R-gui.
> >>>
> >>> There seems to be a hell-hole of problems with the recent updates of R.  But my ver R 3.2.3 GUI 1.66 Mavericks build (7060) query  says that I am up to date with nothing to upgrade.  I would choose not to upgrade entire R if it is having problems with its ‘nightly build’.
> >>>
> >> You really should try the nightly build.  I am using R.app 7116 Mavericks build in OS X 10.11.3 (El Capitan), and am not seeing these problems.
> >>
> >> The latest build for your version of R is labelled _"__R-GUI-7128-3.2-mavericks-Release.dm_g__". <http://r.research.att.com/mavericks/R-3.2-branch/R-GUI-7128-3.2-mavericks-Release.dmg>
> >>
> >> That links to <http://r.research.att.com/mavericks/R-3.2-branch/R-GUI-7128-3.2-mavericks-Release.dmg>. I don't see a loop.
> >>
> >>> ??? what to do with this problem which was ignored the last time I posted it, similar to Dr. Swan’s experience.
> >>
> >> I don't know when you posted that message, but I'd guess you were given the advice you quote above, and you didn't follow it.
> >>
> >> Duncan Murdoch
> >
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac



More information about the R-SIG-Mac mailing list