Comeback of the (infamous) "Error in grid.Call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y, : polygon edge not found" bug?

[privacy]

Hi all,

Executive summary:

• The old Error in grid.call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y, polygon end not found in the middle of the day, while I was not interactively using my Mac
• It happens both from within RStudio, and when running R interactively via the shell

Details below

I am using ggplot2 on a regular (well, hourly) basis, both from within RStudio and from the external R command line (interactive, called from a shell).
Something weird just happened. All running sessions that generates plots (automatically, every few minutes) exited with this error message:

Error in grid.Call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y,  :
  polygon edge not found

For context, I am running the new RStudio 1.3.820 on MacOS (Catalina 10.15.2), with R version 3.5.1.

This is a very old problem that was addressed before (FWIW, I never saw a description of what exactly was done to address it (the R code), which may be relevant to me as I am using R not just from within RStudio)

What is very surprising/puzzling to me is that it all happened at exactly the same minute 3:32pm EDT to be exact. It happened concurrently on R commands running from shell, and from within an RStudio job.
What's even more surprising is that I did not (actively) use my Mac at that point. It was running these jobs as usual, and when I looked at it at 4pm I noticed that all sessions generating plots got this error. Any additional attempts to generate new charts failed with the same error.

The simplest charting attempt will reproduce the error; you don't need anything more sophisticated then:

> data.frame(x=1:9,y=1:9) %>% ggplot(aes(x=x,y=y)) + geom_line()
Error in grid.Call(C_textBounds, as.graphicsAnnot(x$label), x$x, x$y,  : 
  polygon edge not found

The following two observations may shed some light:

• Piping the chart to ggplotly generates and perfectly accurate chart:

    {data.frame(x=1:9,y=1:9) %>% ggplot(aes(x=x,y=y)) + geom_line()} %>% ggplotly(dynamicTicks = T)

• At least when tested from the shell, running extra_font::font_import() seemed to solve the problem for charting instance, but then the problem came back.

I went through all the old blogs discussing this problem, but did not find anything that could explain this.

Will very much appreciate any insight / solution to this. My only workaround at the moment is to pipe everything through plotly , but I do need the charts saved (in files) and rather have them saved also in a regular RDS file as a ggplot2 object, and not just as plotly object that requires a web browser to examine outside of RStudio (I am now always near my machine when I need to look at these files).

Thanks

[nirgrahamuk]

Hello, I'm not so fantastic at this that I can afford to not ask the most basic questions first, please pardon me

I understand that both R console jobs and Rstudio started failing out in their graphics plotting duties, and that now when you run trivial plot request, you receive failure error, and no plot.

Have you reset the sessions ? (Ctrl+Shft+F10)
Sometimes sessions can get corrupted after all.

Alternatively, if you would like something else to try, before that route, it might be worth halting the graphics device. dev.off() and trying that elementary plot again.

Of course, if your issue is persistent, across to new sessions, then I will definitely have to bow out in favour of others with more expertise to think about this.

Regards,
Nir

[privacy]

Hi Nir,

Thanks for your response.
Yes, I have tried all of that (and more). Recall that I also have session that I started from the shell. There I started by just closing devices, either by using dev.off() or by closing their window (has the same effect, as I confirm by using dev.list). I also explicitly created new devices via dev.new(), with and without calling quartz() first. Finally, I did also quick the session and started a brand new one. The problem still occurs.
As for experimenting from within RStudio, I opened new instance of RStudio, e.g. via "open RStudio window". Same problem.

My only intuition/wild-guess, given that it all happened at the same time, is that it has to do with some concurrency bug, maybe in Quartz (even though I'm not sure if RStudio uses Quartz, but the sessions started from command line definitely are). One thing about concurrency bugs is that they can put the system in an invalid state, so then even when plotting only at one device the problem may occur.
San any suggestions/ideas over night (EST), what I will try to do tomorrow is basically closing all quartz graphic devices, inside and outside RStudio, and then create them one by one, and see if I can generate any charts. What I would like to do is basically reset the Quartz window system without quitting all my existing sessions. Then I can try plotting from a new session after I check that no Quartz device is open; any attempt to plot using ggplot will create a new device, but I may also try to create one manually.

It's a wild shot, but at the moment I can't think of any other ways to try addressing the problem, except resetting the whole system, maybe even my computer, which will be quite painful.

Thanks!

[privacy]

An update on this: I think that it was indeed something that had to do with concurrency, or an effect of one process failure with a Quartz window affecting all others.

To cut it short, I noticed that one of the RStudio instances also had problems with the "show in a new window" of code or data frames presented in the code pane. I.e any kind of opening of a new window with that instance was unsuccessful. Once I killed that RStudio instance, I manage to chart again on all other instances (it required in some cases a dev.off() first but the new devices killing the current dev, i.e dev.off(), but new devices worked perfectly well without even the need to restart the session.
Same for the sessions initiated form the shell.

Not sure what exactly caused the problem and its effect on all Quartz graphic devices, but it seems that the problem disappeared once killing the instance that caused the problem.
Hope I didn't jinx it