[R-SIG-Mac] xquartz hanging

Sun Jun 1 00:08:34 CEST 2025

Thanks for the feedback, Marc! Very interesting.

On 5/31/25 13:04, Marc Schwartz wrote:

> Hi,
>
> I am currently running R 4.5.0 on macOS 15.5 (Sequoia), and I also use emacs (30.1) and ess (25.1.0), the latter from elpa, along with other emacs packages.

It seems we (emacs/ess users) are a diminishing crowd :-(
> I do not have the issue that you are referring to below, and did not under prior versions to the best of my recollection.

Then there’s hope :-)
> I do tend to stay up to date on the versions of all of the above and do clean installs of R and packages with each new version, fully removing the older version file tree first (/Library/Frameworks/R.framework).
>
> Thus, you might consider updating both macOS and R to current versions.

I had already planned to upgrade to macos-15.5. I’m not able to
upgrade (fully) to R-4.5 in the immediate future … worse, I need
to have multiple R versions on-hand for some backwards-compatibility
testing (work apps/apis).

I do subscribe occasionally to the “three-finger salute” way of
fixing some OS or program issues, but I really dislike the fact that
it works much more frequently than I think it should.

> I don't use ggplot*, so cannot comment if there may be something specific to that package causing any issues,

|ggplot2| does tend to be more complex and test the graphics device
more than typical base graphics; I recall an issue with ggplot on
windows several years ago that caused the window to dump,
occasionally causing R to dump and crash as well, triggered by a
mouse-wheel action on a ggplot graphics pane. This is not the same
issue, certainly, but speaks to the difference with base graphics.

For the record, while I use it much much less frequently, I have yet
to see the issue appear when a base-graphics plot is displayed. This
is not conclusive.

> One thing that you should do, if you have not, is to be sure to re-install XQuartz after upgrading R versions, and this is referenced on the R macOS CRAN page.

The only mentions I can find of XQuartz on the R-Mac pages are:

  * Big Sur and newer require XQuartz 2.8.5 (I’m good, installed 2.8.5
    from the start)
  * “Always re-install XQuartz when upgrading your macOS to a new
    major version”: not applicable, I’ve been on 15.3 or newer on this
    laptop (unless … is 15.4 a “major version” over 15.3?)

Regardless of that, I don’t understand how an xorg-server would be
at all tied to (needing to be reinstalled/relinked after) changes in
a client library (R plotting services). Can you provide more
information (a link) where they say XQuartz needs to be reinstalled
with each R upgrade? I apologize if I’m missing it on mac.r-project.org.

> See if re-installing XQuartz has any impact on the issues that you are observing.

Regardless of “why” it may work, I think I’m going to uninstall and
reinstall XQuartz when I do the macos upgrade. “It can’t hurt”,
famous last words.
> You might also want to fully uninstall XQuartz first, before re-installing it, and the instructions for that are available on their FAQ page:
>
>    https://www.xquartz.org/FAQs.html

Sage advice, I appreciate it.
> One additional thing to consider is to try to replicate the behavior that you are observing by running R in Terminal and/or via R.app, to try to exclude the possibility that there is something going on with your emacs/ess installation.

That’s been on my list, but since I still don’t know exactly what
causes it to hang, I have not spent the time trying to repeat it
from outside of my normal R use.

Once thing I find interesting is that it is particular to one R
process, but not to XQuartz. That is, when one R process’ graphics
device is hung, I can open a new R process and plotting works
without issue. I can close the first process, eventually its hung
window closes, and other processes continue to plot without issue. I
don’t know if this narrows it down at all, since a bug in either R
or XQuartz could show that specificity. (The major pain is that
often I’m working with many GBs of data, and reloading and
reprocessing is a not-free chore. Usually not impossible, just many
many minutes and reacquiring my mental focus.)

Thanks again for your experience, Marc!

> If you can replicate the issues in Terminal and/or R.app, that would help to exclude emacs/ess from involvement at least. If you cannot, then you might be sure that you are running the latest versions of emacs and ess to see if that helps, in case they are adding a source of conflict.
>
> Regards,
>
> Marc Schwartz
>
>
>> On May 31, 2025, at 10:35 AM,bill+rsigmac using 8pawexpress.com wrote:
>>
>> Are there easy fixes or alternatives to using XQuartz for R plots?
>>
>> I’m running R-4.4.3 (emacs/ess) on macos 15.4.1 and have xquartz-2.8.5
>> installed. Most of the time plotting in R works well enough (I tend to
>> use ggplot2, I don’t know if it happens as often with base plots).
>> Occasionally (several times a week), “something” happens with the plot
>> window, and from then on that R process can no longer plot anything
>> more. The “something” is not well defined for me yet, I think it’s a
>> mouse-wheel or mouse-click or similar; the snark in me says “well don’t
>> do that”, but I cannot nail down exactly how/when it breaks, it just does.
>>
>> When it happens, the current device window is still open, but it has a
>> mac spinning-colorwheel, no new plotting commands work, and I cannot
>> close the window myself. I cannot dev.off() it, nor does dev.new() give
>> me a new plotting window. When this happens for a particular R process,
>> my only options for plotting are either (a) close the R process and
>> start over, or (b) manually plot to a PDF or similar one-shot graphics
>> device, viewing in a different app.
>>
>> There are several related issues I can find:
>>
>> https://github.com/XQuartz/XQuartz/issues/431, specific to macos 15.4 or
>> newer I think; some mention of “minimizing windows” but I don’t minimize
>> my plot windows, so perhaps not that
>> https://github.com/XQuartz/XQuartz/issues/168, closed as “not planned”,
>> though this one is much older than the first (431) issue
>>
>> I’ve tried using something like |httpgd|
>> <https://github.com/nx10/httpgd/> since it can (mostly) provide an
>> “always updating graphics device” for example without xquartz.
>> Unfortunately, with some other packages (namely plumber that I use
>> frequently-enough) it can put the R’s REPL into an unbreakable state
>> (#215<https://github.com/nx10/httpgd/issues/215>). If that were fixed
>> I’d be a lot more comfortable using that as my workaround.
>>
>> My research has not shown any other options for fixing or replacing
>> xquartz with a more stable solution. Are there good ways to troubleshoot
>> and try to fix the xquartz issue? Does anybody else have a workaround or
>> alternative that is less unwieldy than pdf(..); plot(..); dev.off()?
>>
>> Thanks,
>> Bill
>>
>> 
>> 
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

	[[alternative HTML version deleted]]