R.app GUI 1.71 (7827) crashes on Catalina

I jumped the gun on this. I rebooted and the pinwheel of death is back when
I open a second file in the editor.

Bummer.

On Sat, May 23, 2020 at 11:31 AM Brandon Hurr <brandon.hurr at gmail.com>
wrote:

Kevin had a suggestion that I toggle disk access in the Security settings,
building on Bob's original comment to give R full disk access. As soon as I
turned it off, it no longer crashed upon load. I turned it back on and it
didn't crash then either. I have been testing for a few days now and I can
no longer cause it to crash like it used to.

Hiroshi, I suggest trying that as well and see if it solves your problem
too.

Thanks for helping dig on this issue.
Brandon

On Wed, May 20, 2020 at 4:24 PM Simon Urbanek <simon.urbanek at r-project.org>
wrote:

Unfortunately I cannot reproduce it. When opening a file in one of the
protected folders with R 4.0.0 release on Catalina I get '"R" would like to
access files in your Documents folder' - which you have to agree to (one of
those Catalina annoyances). It only asks once - we don't explicitly control
it, so I wonder if there is some interaction ?

Cheers,
Simon

On May 21, 2020, at 10:58 AM, Brandon Hurr <brandon.hurr at gmail.com>

wrote:

I just want to add that this is still happening. The size of the
script seems to be irrelevant (10s of lines). If you double click
another .R file for R GUI to load it gives the beachball of death and
R maxes out 1 of my cores. Are there specific logs or files that would
be helpful beyond what has been supplied?

Thanks,
Brandon

On Mon, May 4, 2020 at 5:39 AM Bob Rudis <bob at rud.is> wrote:

Aye, I should have noted that Apple's `tccd` and entire TCC (privacy)
subsystem is super buggy/noisy. Enough of them that there are a fw
third-party apps like Taccy
(

https://urldefense.com/v3/__https://eclecticlight.co/taccy-signet-precize-alifix-utiutility-alisma/__;!!Mih3wA!RJVCh9VfCoz3T_2M05bjyLjXayhKn0WRsh2X4wrwNKDorPrQmKY4NxTjTzjfoVM$ )

to help privacy-perms issues. The GUI code does not try to do things
`tccd` would balk at, and this particular sandbox error shows up in
many general apps/FOSS projects outside of R GUI.

On Mon, May 4, 2020 at 8:13 AM Hiroshi Hakoyama
<hiroshi-hakoyama at nagano.ac.jp> wrote:

The sandbox error also happened for test2.R that can open without

trouble.

So, this might not be the critical error.

I uploaded the two devices logs for test.R and test2.R:

https://urldefense.com/v3/__https://hako.space/R/devices_log_for_test_R.txt__;!!Mih3wA!RJVCh9VfCoz3T_2M05bjyLjXayhKn0WRsh2X4wrwNKDorPrQmKY4NxTj-SyhUy8$ 
https://urldefense.com/v3/__https://hako.space/R/devices_log_for_test2_R.txt__;!!Mih3wA!RJVCh9VfCoz3T_2M05bjyLjXayhKn0WRsh2X4wrwNKDorPrQmKY4NxTjWtZz14g$ 

Best regards,

Hiroshi

2020/05/04 20:29?Hiroshi Hakoyama <hiroshi-hakoyama at nagano.ac.jp

????:

Thank you for responses.

I installed the debug build R.app GUI 1.71 (7834) to MacBook Air

(2012, 4G RAM, Catalina 10.15.4), and double-clicked test.R. The result is
the same GUI hang. The following is a part of the device log:

...
default       19:56:06.123133+0900    R        - 1 documents to open
default       19:56:06.123188+0900    R        -

application:openFile:/Users/hako/Desktop/test.R called

default       19:56:06.123316+0900    R        - intial start,

changing wd to pathname whic is /Users/hako/Desktop/

error 19:56:06.126663+0900    tccd    {ID: com.apple.sandboxd,

PID[155], auid: 0, euid: 0, binary path: '/usr/libexec/sandboxd'} attempted
to call TCCAccessRequest without the
com.apple.private.tcc.manager.check-by-audit-token entitlement

default       19:56:06.127340+0900    tccd    PID[155] is checking

access for target PID[655]

default       19:56:06.136847+0900    tccd    -[TCCDAccessIdentity

staticCode]: static code for: identifier org.R-project.R, type: 0:
0x7fa62ad38b10 at /Applications/R.app

...

The error line seems to be similar with Brandon's cases.


Best regards,


Hiroshi

2020/05/02 11:18?Brandon Hurr <brandon.hurr at gmail.com>????:

I have a mac mini as well that does not show this crash. It's much
beefier (6-core i7, 32 GB RAM probably not relevant).
Here is the same boot up log with the same file and it does not

crash R.

https://urldefense.com/v3/__https://gist.github.com/bhive01/2a48fa3e6fd70ae1b974184ad7b947ba*file-r-gui_pid4422_working_console-log__;Iw!!Mih3wA!RJVCh9VfCoz3T_2M05bjyLjXayhKn0WRsh2X4wrwNKDorPrQmKY4NxTjZZHVqhs$ 

I look at the transition where the two differ and the crash happens
and the one that works is much shorter. At line 319 in the

non-working

MBA (PID 889) it "makes presenter" and then stops. Making presenter
doesn't happen until line 4261 in the working file. Lots of parsing

of

the file is missing (4000 lines of it).

B

On Fri, May 1, 2020 at 6:48 PM Brandon Hurr <brandon.hurr at gmail.com>

wrote:

Thanks Bob.

I did this and it did not fix it sadly.
I downloaded the Debug version of R-GUI and captured the following
after clicking on the same file (which did cause it to crash again)
Here is the console log for the R PID (889 in this instance) from
loading R to then clicking to load the same file (which froze my
system again):
https://urldefense.com/v3/__https://gist.github.com/bhive01/5efa02237085c7a3ccf6d137e04f7c45__;!!Mih3wA!RJVCh9VfCoz3T_2M05bjyLjXayhKn0WRsh2X4wrwNKDorPrQmKY4NxTjrmA89co$ 
Here is the full Apple Crash Log that came up after I force quit R:
https://urldefense.com/v3/__https://gist.github.com/bhive01/0eeb32d0a666f875e83440268b69aefd__;!!Mih3wA!RJVCh9VfCoz3T_2M05bjyLjXayhKn0WRsh2X4wrwNKDorPrQmKY4NxTjfzfw5XY$ 

I hope this is helpful. Please let me know if I need to dig more

and

recommendations for doing so.

Thanks,
B

On Fri, May 1, 2020 at 5:54 PM Bob Rudis <bob at rud.is> wrote:

Suggestion: try adding R.app to "Full Disk Access" in the Privacy

tab

under Security & Privacy system preferences.

I'm not experiencing these issues (just now when I tried it; I
generally don't use R.app)

On Fri, May 1, 2020 at 4:54 PM Brandon Hurr <

brandon.hurr at gmail.com> wrote:

I'm going to add to the pile on this one. It's hard to nail down
though. I was able to load Hiroshi's test.R script after loading

up

R-GUI 7827 and just now 7832. I loaded it from multiple

directories by

clicking on it.
That said, I've been having many issues locking up R-GUI on my

2019

MBAir since upgrading to R4.0.0. I can click and load R-GUI with

a

script file, but if I want to load another script it gives me the
colored pinwheel of death. Sometimes it will load up R-GUI, but

then

pinwheel of death on loading a lengthy script. I'm not sure the

length

is the issue.

I played around with the console a bit and noticed these

messages pop

up when it locks up R:
error    13:49:54.173449-0700    kernel    Sandbox: garcon(763)
deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic

Ltd)/Data

standardisation/Database Converts/Conversion script DEV.R
error    13:49:54.243397-0700    kernel    Sandbox: garcon(763)
deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic

Ltd)/Data

standardisation/Database Converts
error    13:49:54.312989-0700    kernel    Sandbox: garcon(763)
deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic

Ltd)/Data

standardisation
error    13:49:54.344345-0700    kernel    Sandbox: garcon(763)
deny(1) file-read-xattr /Users/brandonhurr/Dropbox (BioLumic Ltd)

A rough guess here is that the sandboxing isn't working right

(or is?)

and is blocking access of R-GUI to the file which then locks up
because it's waiting for data?

Anyone else seeing this behavior and have a better idea how to

pin it down?

Thanks,
B


On Thu, Apr 30, 2020 at 6:07 AM Hiroshi Hakoyama
<hiroshi-hakoyama at nagano.ac.jp> wrote:

Dear All,

Environment:
R version 4.0.0 (2020-04-24) -- "Arbor Day"
[R.app GUI 1.71 (7827) x86_64-apple-darwin17.0]
macOS: Mojave and Catalina
Removed file for the test: .Rapp.history

Description:
R.app crashes when a large file (e.g., test.R) is

double-clicked on Mojave and Catalina. The crash does not occur on High
Sierra. Small source files (e.g., test2.R) do not cause the crash on Mojave
and Catalina.

How-To-Repeat:
Double-click test.R (or open test.R using R.app) on Catalina or

Mojave.

Fix:
unknown

Crash Report is too large to paste to the email.


Best regards,

Hiroshi Hakoyama
Nagano University

test.R

###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################

x <- rnorm(100000)
y <- rnorm(100000)
hist(x)
hist(y)

test2.R
x <- rnorm(100000)
y <- rnorm(100000)
hist(x)
hist(y)

system.log
Apr 30 20:54:40 ec7 R[1147]: assertion failed: 19E287:

libxpc.dylib + 92807 [32B0E31E-9DA3-328B-A962-BC9591B93537]: 0x89

	[[alternative HTML version deleted]]