Issues with rgl in CRAN not loading

[will-rogers]

I have XQuartz 2.7.11, MacOS Big Sur V11.2, R version 4.0.3. I have downloaded rgl from both the repo here on git with devtools::install_github("dmurdoch/rgl") and through CRAN, but both packages fail to load in R with no warning message after ten minutes. The initial installs had no warning messages or error messages. This package is a dependency for the rayshader library (which I have used successfully in the past). Any help would be appreciated!

[stuartE9]

I have a similar problem but on MacOS Catalina 10.15.7. R version 4.0.3 in RStudio. XQuartz 2.7.11. I have updated my R version and all packages. I reinstalled XQuartz and rgl but 'library(rgl)' hangs indefinitely without any error message. This freezes RStudio necessitating a 'force quit'.

Any assistance much appreciated. It looks to be a great package!

[dmurdoch]

You can askrgl to load without making use of XQuartz by setting the R option options(rgl.useNULL = TRUE) before library(rgl). (Alternatively, set the environment variable RGL_USE_NULL=TRUE.) You won't be able to view rgl display windows, but rglwidget() should still work.

If anyone who has this problem is able to debug it, I'd appreciate information on exactly where the hang is occurring. I don't see it on my MacOS Catalina machine.

[dmurdoch]

Another point that might help: I believe updates of XQuartz have no effect until you reboot the system. It's not enough to reinstall it without rebooting.

[will-rogers]

@dmurdoch what could I do to provide more info? As @stuartE9 mentioned, I don't get any error messages on my end when running library(rgl). Thanks!

[will-rogers]

It has to be something with R's connections to x11, I just reinstalled xquarts, rebooted my computer, opened xquarts, and then tried to run "x11()" which failed to run. Does anyone know how to determine R's connection to x11/repair it?

[dmurdoch]

@wilrogers: Could you confirm that you have rebooted your machine since the XQuartz update? Also, does the advice about rgl.useNULL help?

Going beyond answering those questions needs a fairly big step: you'd need to run R with debuggers to see where it is stuck when it locks up. If you haven't done that before, expect to spend a while learning how it all works. Here's a short list of the steps:

• On MacOS you need to install the build tools including the Xcode command line tools so you can build rgl. Details of what to install are in the R Installation and Administration Manual.
• Add browser() to the start of the source code of the .onLoad function in rgl/R/zzz.R and rebuild the package. This will trigger the R debugger and let you single-step through the initialization so we can see which line of R code is running when you lock up.
• For more detail, you need to run R under a debugger. For this you'll need lldb installed. It should be part of the Xcode command line tools. However, you also need to install a special version of R for it to work: see R for MAC OS FAQ 10.17, here: https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R
• Then from a terminal, you can run R -d lldb, type run at the prompt, and R will start up. Run library(rgl) and if it locks up like you've been seeing before, Cmd-C should break to the debugger and you can print out useful information like a stack trace.

• I'd find it helpful if I knew how far you get through .onLoad before locking up, and what the stack trace is like at that time. But I'll repeat the warning: the first time you go through the steps above, you're likely to find it quite time-consuming and a little confusing.

[dmurdoch]

Our messages crossed. If x11() causes problems, then options(rgl.useNULL = TRUE) before library(rgl) should definitely help. You won't be able to view rgl windows in R, but you can still call rglwidget() to see them in your browser.

As to fixing Xquartz, there was an update very recently. Maybe installing the previous version would work better for you, or you could look for help on their page. Maybe this issue https://github.com/XQuartz/XQuartz/issues/54 is relevant?

[will-rogers]

Gotcha, I will try these and get back! Thanks for your help!

[stuartE9]

Thanks for your efforts to solve this problem. I tried a couple of things (unfortunately without success):

Install the previous version of XQuartz (2.7.10) - X11() hangs immediately in RStudio console

Tried the rgl.useNULL=TRUE line before opening rgl - library(rgl) hangs immediately

Deleted XQuartz, ran rgl.useNULL = TRUE, then library(rgl) hangs immediately.

So it seems that the problem may be unrelated to XQuartz?

Stu

On Feb 6, 2021, at 12:42 PM, dmurdoch notifications@github.com wrote:

Our messages crossed. If x11() causes problems, then options(rgl.useNULL = TRUE) before library(rgl) should definitely help. You won't be able to view rgl windows in R, but you can still call rglwidget() to see them in your browser.

As to fixing Xquartz, there was an update very recently. Maybe installing the previous version would work better for you, or you could look for help on their page. Maybe this issue XQuartz/XQuartz#54 https://github.com/XQuartz/XQuartz/issues/54 is relevant?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dmurdoch/rgl/issues/11#issuecomment-774513476, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGGU4C25LBW3FOVO6H4L4DS5V5Q7ANCNFSM4XCHGXOA.

[dmurdoch]

With the standard build of rgl, it always tries to link to the X11 libraries, so they'll end up being loaded whether rgl uses them or not. Since you're having problems calling X11(), it sounds as though that's what is causing your system to hang. That's definitely related to XQuartz, but I don't know how to fix it.

On the other hand, if you're able to build rgl from source, you can instruct it not to try to link to the X11 libraries. This needs various Xcode tools; then running

install.packages("rgl", configure.args = "--disable-opengl", type = "source")

will rebuild it that way. You can still use rglwidget() to display rgl output in RStudio or in a browser.

[dmurdoch]

Perhaps the rgl install should install two versions of the library, the current one, and another with OpenGL disabled. Then if rgl.useNULL is true at startup time it would load the safer one.

This makes the build more complicated and the size of the install bigger, but it would be doable.

[SridharJagannathan]

@dmurdoch I debugged this issue a little bit, I tried downgrading the XQuartz version to 2.7.10 and the issue still appeared. The main issue is that when you call library('rgl') the call never returns and is just stuck somewhere inside. I tried building from sources and then again while in the last step of trying to check if the install works, I had the same situation where in the call never returns. Further, I tried to simply devtools::load_all(".") and then it started complaining about

Error in library.dynam(dynlib, pkg, lib) : 
  shared object ‘rgl.so’ not found 

While debugging further, I noticed that it wanted the library in a folder called libs inside the main folder, so I did the same (by copying all the files from src to libs), and then it was stuck now in https://github.com/dmurdoch/rgl/blob/master/R/zzz.R#L42. It seems inside the function library.dynam when the file rgl.so is loaded the invisible(dll) never returns.

In short: There is some problem in the loading of this rgl.so file and the control never comes back from invisible(dll). I think this is the issue which most people suffer from when they do library('rgl')

Hope this is useful for you to sort this issue. @jefferis: FYI

[SridharJagannathan]

To comeback to the debugging steps that you suggested before (with lldb), here is a print of the stack trace:

> library('rgl')
Process 21931 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff79f7161a libsystem_kernel.dylib`__select + 10
libsystem_kernel.dylib`__select:
->  0x7fff79f7161a <+10>: jae    0x7fff79f71624            ; <+20>
    0x7fff79f7161c <+12>: movq   %rax, %rdi
    0x7fff79f7161f <+15>: jmp    0x7fff79f6a421            ; cerror
    0x7fff79f71624 <+20>: retq   
Target 0: (R) stopped.

[dmurdoch]

@SridharJagannathan, does running x11() work for you? It loads the same X11 libs as would be needed by rgl. Some others have found that it has the same problem, which indicates that the problem is with those libraries. You can currently avoid linking to them by installing from source as described in https://github.com/dmurdoch/rgl/issues/11#issuecomment-774699179 . I'm currently testing a solution that will make this possible with a binary install.

[SridharJagannathan]

Thanks, Indeed running x11() in the r console just keeps going without ending. Your solution of installing stuff like install.packages("rgl", configure.args = "--disable-opengl", type = "source") did work for me. But in our packages like nat we use functions like plot3d that displays stuff on the Xquartz window and hence I was hoping for a solution on those lines. But when I run rglwidget() i can indeed see the plots on the viewer tab. Do you know who to contact to fix stuff with x11()?

[dmurdoch]

x11() is a base R function, but the real problem lies in XQuartz or MacOS. On the XQuartz page, this issue https://github.com/XQuartz/XQuartz/issues/66#issue-803786687 might be related, and it suggests setting the DISPLAY variable. You can do that from within R using Sys.setenv(DISPLAY=":0.0"). You would do this before library(rgl) (or some other package that causes rgl to load).

[jefferis]

A lot of people use rgl + x11 on a mac, and have been using MacOSX 10.15 if nor 11.X for a little while now. I therefore think this problem must be of recent origin. A couple of ideas:

1. the most recent macosx security update (1 Feb) changed something. However, I can't see anything obvious in the change list.
2. a botched Xquartz 2.8.0_beta install has changed an X security/DISPLAY setting and this is not reverted by going back to previous X11 versions. But I think some of the posters above never updated to 2.8.0.

Note that that there used to be a requirement to log in and out of your MacOSX session after installing/upgrading XQuartz.

XQuartz-2.7.11 has been the stable release for more than 4 years so I can't see any reason to downgrade even further.

[SridharJagannathan]

Ok, I think i got it working now.. What I basically did was: 1) Deleted all the folders/subfolders inside /opt/X11/ (and also deleted everything that had something to do with x11) 2) Restarted mac, and then installed the Xquartz 2.7.11 3) Now installed rgl like install.packages('rgl') 4) Now, I tried to plot some stuff, which actually works.. :)

I think @jefferis is right in that, even if you uninstall and install X11, there are some residuary stuff around, I think just deleting them all and restarting the mac, and then installing rgl seemed to do the trick.

[kasperdanielhansen]

Coming here from r-sig-mac. Just FYI: XQuartz on OS X have not been updated in a while (current stable release is from 2016), but that is changing now with the recent M1 release, so the XQuartz team is working on 2.8.0. I have just been asked to install 2.8.0-beta3 despite not signing up for the beta release. It's clear that "soon" we will have a new XQuartz release which might be a large update since it has been 4.5 years.

It might be nice to know if people are actually running 2.8.0-beta3 and/or are on an M1 CPU.

[SridharJagannathan]

To clarify the specs I'm working under: OS: macOS 10.14.6 (18G103) - Mojave Hardware: Macmini7,1 (Intel Core i5) The issue that i was having was upon a fresh install, of R- Studio (1.4.1103), R (4.0.4 RC), I installed XQuartz 2.7.11 ( i never checked if rgl worked at this point), however I was prompted to update that to 2.8.0 beta version. Then after installing the beta version, the rgl did not work. So I tried to get back to previous versions of Xquartz, which is not trivial as just uninstalling won't do the trick. My solution would work in case if you want to go back to previous working version of Xquartz. But i think the general idea of @dmurdoch is the way to go: 1) as this will prevent users getting stuck in library('rgl') 2) This will also help people in the future if they have x11 problem they would still be able to use rgl

[stuartE9]

I did install the Xquartz 2.8.0_beta early in this saga. rgl reacted negatively to it (sorry - did not think to record the details at that point). I 'removed' it and went back to 2.7.11 (or so I thought) and then tried 2.7.10 with no success.

On Feb 8, 2021, at 8:31 PM, Gregory Jefferis notifications@github.com wrote:

A lot of people use rgl + x11 on a mac, and have been using MacOSX 10.15 if nor 11.X for a little while now. I therefore think this problem must be of recent origin. A couple of ideas:

the most recent macosx security update (1 Feb) changed something. However, I can't see anything obvious in the change list https://support.apple.com/en-gb/HT212147. a botched Xquartz 2.8.0_beta install has changed an X security/DISPLAY setting and this is not reverted by going back to previous X11 versions. But I think some of the posters above never updated to 2.8.0. Note that that there used to be a requirement to log in and out of your MacOSX session after installing/upgrading XQuartz.

XQuartz-2.7.11 has been the stable release for more than 4 years so I can't see any reason to downgrade even further.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dmurdoch/rgl/issues/11#issuecomment-775586382, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGGU4GXRVF7XO4G755S5FTS6CGA3ANCNFSM4XCHGXOA.

[jefferis]

@stuartE9 as @SridharJagannathan noted, unfortunately it seems likely that you will need to do more to clean up what was left by the 2.8.0 beta install.

[dmurdoch]

@stuartE9 : did you try the suggestion of explicitly setting DISPLAY using Sys.setenv(DISPLAY=":0.0") before trying to load rgl?

[SridharJagannathan]

@dmurdoch : I think the parameter of display is not inherited directly when the subprocess like install are being called from r studio. so setting the env var inside r studio doesn't work (I did try this solution before). I think the main problem was that the previous install left some temporary file, like port etc. Which are again being loaded up even when you reinstall xquartz and start again. @stuartE9 : I recommend to:

1. uninstall xquartz,
2. uninstall rgl
3. delete all x11 stuff a) if you installed from here, then you should remove all stuff under /opt/X11, if you installed from macports then they will be in a different location b) remove all temporary settings like property list, they will be named like: org.macosforge.xquartz.startx.plist, org.xquartz.startx.plist (or) org.macports.startx.plist (if you installed from macports) c) also, when you do Sys.getenv("DISPLAY"), it will return stuff from temporary folder like say: "/private/tmp/com.apple.launchd.B0ivnElpRV/org.macosforge.xquartz:0" delete that folder as well.
4. restart.
5. install xquartz (stable version).
6. Now open terminal and type some x command like xclock. You should see the clock running.
7. The previous step would have overwritten any temporary file that was residue as well.
8. Now restart.
9. Install rgl from cran with source like:

     install.packages("https://cran.r-project.org/src/contrib/rgl_0.104.16.tar.gz", 
     repo=NULL, type="source")

10. The install should succeed, then finally to library('rgl') to see if it works

[dmurdoch]

@SridharJagannathan : Your description isn't very precise. What is "all x11 stuff"? In your original description in https://github.com/dmurdoch/rgl/issues/11#issuecomment-775595356, you said all files and folders in /opt/X11, "and also deleted everything that had something to do with x11". What did you delete?

[stuartE9]

nice -

tried to replicate your steps but unfortunately did not get the same good result - still hangs on library(rgl)

On Feb 8, 2021, at 8:54 PM, Sridhar Jagannathan notifications@github.com wrote:

Ok, I think i got it working now.. What I basically did was:

Deleted all the folders/subfolders inside /opt/X11/ (and also deleted everything that had something to do with x11) Restarted mac, and then installed the Xquartz 2.7.11 Now installed rgl like install.packages('rgl') Now, I tried to plot some stuff, which actually works.. :) https://user-images.githubusercontent.com/13106358/107304616-5683d700-6a79-11eb-9c43-9aabdb0a4516.png I think @jefferis https://github.com/jefferis is right in that, even if you uninstall and install X11, there are some residuary stuff around, I think just deleting them all and restarting the mac, and then installing rgl seemed to do the trick.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dmurdoch/rgl/issues/11#issuecomment-775595356, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGGU4HY4Y45VSBP3RIG253S6CIUZANCNFSM4XCHGXOA.

[dmurdoch]

@stuartE9 : Please try the following:

1. Reboot your system.
2. Start R.
3. Print the result of Sys.getenv("DISPLAY")
4. Run Sys.setenv(DISPLAY = ":0.0")
5. Run library(rgl).

Please let me know the results.

[SridharJagannathan]

@SridharJagannathan : Your description isn't very precise. What is "all x11 stuff"? In your original description in #11 (comment), you said all files and folders in /opt/X11, "and also deleted everything that had something to do with x11". What did you delete?

@dmurdoch : Sorry, I have updated the instructions in much more detail now, to include exactly the stuff that i deleted. @stuartE9 : I have update the instructions in detail now, Can you try this out as well, and tell me the exact place where it is failing? (Do you see the clock in Step6)

[stuartE9]

@SridharJagannathan - In step 3 I have deleted /opt/x11 in its entirety which I assume addresses 3a. Will that also include the files in 3b or are they at a different location? If so, please let me know where. thanks for your help

[stuartE9]

@dmurdoch Here's a screenshot of the requested session....

[SridharJagannathan]

@SridharJagannathan - In step 3 I have deleted /opt/x11 in its entirety which I assume addresses 3a. Will that also include the files in 3b or are they at a different location? If so, please let me know where. thanks for your help

@stuartE9 The files in 3b, 3c are in a different location, so please search them in your system and remove them. For your 3c, you can delete the folder from your display variable "/private/tmp/com.apple.launchd.ySHyOCJxXI"

[dmurdoch]

@SridharJagannathan : Honestly, I can't support your recommended approach for dealing with this issue. If people follow your instructions and it fixes things, that's great: but there are a lot of opportunities to cause serious problems when you do as much deleting as you're recommending, if someone makes a mistake while typing.

I'd really prefer a much more targeted approach. That takes some work to develop. First you need a way to reproducibly trigger the issue, then a lot of time needs to be spent trying to minimize the number of changes needed to fix it. I'd be happy to find the minimal fix, but I've never seen this issue on my own system, and haven't heard of what I'd need to do to trigger it.

[will-rogers]

Granted, it would be great if there was an easier or more straightforward fix @dmurdoch , but the advice from @SridharJagannathan seems to have worked! I cant seem to run xclock or other functions (maybe I deleted too much haha). But I can run rglwidget() in Rstudio and view 3D plots of ourput.

[dmurdoch]

@wilrogers : If you can't run xclock, it didn't work. You could have done nothing but install the latest rgl from Github to get where you are now.

What happens if you try to run x11() in R?

[dmurdoch]

@SridharJagannathan : The symptoms described by @wilrogers sound like your solution did not fix the issue. It appears he has damaged X11 enough that rgl detects the damage at startup, and doesn't try to use it. I have therefore hidden your post. I had to mark it "outdated", because Github doesn't offer a choice of "may be dangerous advice".

[SridharJagannathan]

@SridharJagannathan : The symptoms described by @wilrogers sound like your solution did not fix the issue. It appears he has damaged X11 enough that rgl detects the damage at startup, and doesn't try to use it. I have therefore hidden your post. I had to mark it "outdated", because Github doesn't offer a choice of "may be dangerous advice".

@dmurdoch: First of all, thank you for maintaining this package and your constant inputs, but I'm afraid your understanding of the issue is incorrect. The files that I asked to remove are actually present in ~/Library/Preferences (please refer to this article in the section 3 (https://www.uninstallmacapp.com/xquartz-x11-removal.html#:~:text=Open%20the%20Applications%20folder%20in,to%20begin%20the%20uninstall%20process.)) I certainly do not think this is dangerous to remove temporary files and property list (user settings) that they would go on to damage the x11. I think it has solved @wilrogers problem, otherwise the rgl window would not appear. However he is using BigSur as the operating system which is fairly new, and he did not report if xclock was working in his system before this operation. I will try and check to report back on how this works in BigSur

The suggestions that i offered are only advices to overcome this problem and not solutions per se.

I foresee only two solutions to this problem:

1) Xquartz updates and produces a new version. (or) 2)rgl detects if there was any problem in x11 (before loading the same) and switches to a default strategy without x11.

I guess the ideal solution from the rgl side would be implement some form of 2 (which I think you are already trying to do).

Now coming back on how to reproduce the problem yourself: 1) Please install the beta version from here: https://www.xquartz.org/releases/XQuartz-2.8.0_beta3.html 2) now once you do library('rgl') you should see the problem that rgl never loads.

[dmurdoch]

@SridharJagannathan : It has certainly not solved @wilrogers's problem. As he said, "I cant seem to run xclock or other functions (maybe I deleted too much haha). But I can run rglwidget() in Rstudio and view 3D plots of ourput." Not being able to run xclock is a sign that X11 is broken. Running rglwidget() doesn't use X11 at all, it gets the browser (in his case the one built in to RStudio) to handle the display.

As to reproducing the problem: I have been using the Xquartz beta since it was pushed to my machine. I've just reinstalled it, and things are fine. It reports itself as "XQuartz 2.8.0_beta3 (xorg-server 1.19.7)". I'm not on Big Sur, I'm running Catalina, but I've seen reports of people having the problem on Catalina as well (e.g. @stuartE9). There's something different about systems that show the problem, and I don't know what it is.

[will-rogers]

@dmurdoch @SridharJagannathan @stuartE9 sorry for all the confusion I caused - I am very new to these issue boards and coding in general. I followed the advice here https://github.com/tylermorganwall/rayshader/issues/26. I downloaded the beta version of Xquarts, uninstalled rgl via R, I restarted my computer, booted up xquarts, ran xclock, and then booted up R and installed RGL from the source using install.packages. Hopefully this is clear enough for others. I figured out that the "x11" files I deleted were associated with an old anaconda llibrary I had used for some tensor flow models, so they shouldn't have affected R at all anyway. As you point out @dmurdoch, I didn;t fix any problems originally, I just found a workaround with rglwidget(). Now however, I have an actual RGL device appearing.

[dmurdoch]

@wilrogers : Good to hear you have it working. Just one suggestion: if you followed those instructions exactly, you won't have the latest version. The main development home for rgl is now here on Github, so you would use

remotes::install_github("dmurdoch/rgl")

to get it.

[dmurdoch]

I've finally managed to reproduce this. The key for me to see the bug was to install the 2.8.0 beta, then install the 2.7.11 regular version. The trouble is that there are entries in

/Library/LaunchAgents and /Library/LaunchDaemons

that were created by the beta and were not removed or changed by the new install. Deleting those files (both named org.xquartz.startx.plist) and reinstalling 2.7.11 seems to have fixed things for me.

There's another issue to worry about, however. If someone using the beta builds rgl, the binary will only work in the beta. I didn't try it, but I suspect if rgl is built against 2.7.11, the binary will only work there. So if you get messages asking you to install Xquartz when you already have it installed, you probably need to install rgl from source instead of the CRAN binary.

[stuartE9]

Sorry I never closed this out with you - I've been traveling and put that project aside. I have now installed the new 2.8.0 beta and rgl is running as expected. (rgl CRAN binary).

Thank you for your time and effort to resolve the problem!

Stu

On Feb 13, 2021, at 8:56 PM, dmurdoch @.***> wrote:

I've finally managed to reproduce this. The key for me to see the bug was to install the 2.8.0 beta, then install the 2.7.11 regular version. The trouble is that there are entries in

/Library/LaunchAgents and /Library/LaunchDaemons

that were created by the beta and were not removed or changed by the new install. Deleting those files (both named org.xquartz.startx.plist) and reinstalling 2.7.11 seems to have fixed things for me.

There's another issue to worry about, however. If someone using the beta builds rgl, the binary will only work in the beta. I didn't try it, but I suspect if rgl is built against 2.7.11, the binary will only work there. So if you get messages asking you to install Xquartz when you already have it installed, you probably need to install rgl from source instead of the CRAN binary.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dmurdoch/rgl/issues/11#issuecomment-778707748, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGGU4B6NXPDUGQKNX3GO43S64UVNANCNFSM4XCHGXOA.