traceback() for no applicable method for 'depth' applied to an object of class "NULL"

[joethorley]

This error has been reported previously (in issue #2514) where @hadley wrote.

Unfortunately there's not much I can do without a reprex. If you see it again, at least try capturing a traceback() and filing a new issue.

Originally posted by @hadley in #2514 (comment)

It frequently but unpredictably occurs when printing ggplot objects by sourcing a script.
As it's unpredictable I'm not able to provide a reprex however I am providing a traceback() as suggested.

Error in UseMethod("depth") : 
  no applicable method for 'depth' applied to an object of class "NULL"
In addition: There were 13 warnings (use warnings() to see them)
> traceback()
16: depth(path)
15: upViewport(depth(vp), recording = FALSE)
14: popgrobvp.viewport(x$vp)
13: popgrobvp(x$vp)
12: postDraw.grob(x)
11: postDraw(x)
10: drawGTree(x)
9: recordGraphics(drawGTree(x), list(x = x), getNamespace("grid"))
8: grid.draw.gTree(gtable)
7: grid.draw(gtable)
6: print.ggplot(gp)
5: print(gp) at predict-abundance.R#138
4: eval(ei, envir)
3: eval(ei, envir)
2: withVisible(eval(ei, envir))
1: source("predict-abundance.R")

[joethorley]

I'm also willing to work with someone to try and narrow it down.

[yutannihilation]

The similar traceback on sdesabbata/BivariateTMap#2 is of tmap, so it seems this error is not specific to ggplot2. I'm afraid there's nothing we can do...

[hadley]

I think this is something that @thomasp85 will eventually pick up as part of his general graphics/grid work.

[r2evans]

Update: nope, this didn't work, kept for history.

---

Since all of the error message I see are about methods and NULL, can we simply just add a depth.NULL S3 method?

depth.NULL <- function(x, ...) 1

The current definitions of grid::depth.* (github) all appear to return numbers, so this seems reasonable. I don't know if 0 would be better than 1, to be honest, but while I can see that 0 might make sense here (to mean: don't know, let's assume none), I don't know if grid:: functions expect the depth to be 1+ or 0+.

For troubleshooting, it might be beneficial to use this instead, not sure that I know what to do once I hit that debugger.

depth.NULL <- function(x, ...) { browser(); 1; }

[thomasp85]

@pmur002 do you have any insight as to what may cause this error? #2514 lists a range of observations about what may cause it... Could it potentially be related to garbage collection as it seems to disappear when the plot is assigned to a variable instead of just being drawn (note: plots shouldn't get garbage collected as they are kept in the the .last_plot object)

[thomasp85]

Side note... This error consistently comes up when checking patchwork on Ubuntu on R 3.2 - 3.5, but not on 3.6... was this fixed in the latest release?

https://github.com/thomasp85/patchwork/runs/319176273

[r2evans]

I can reproduce the error even when storing as a variable, so I believe that that is not the culprit (or at least the only one ... idk).

My steps to reproduce involve a multi-monitor extended desktop. Using just R (within emacs/ess):

1. Start a simple plot.

   library(ggplot2)
   p <- ggplot(mtcars,aes(mpg,disp))+geom_point()
   p

2. "Snap" the window; I have reproduced the crash when it is maximized or full-height snapped onto either the left or right. (Because of this, I wonder with no verification whether the crash has something to do with Windows forcefully redefining desktop size that includes a pixel row/column on which the window resides.)

3. Disconnect the second monitor.

   # Error in UseMethod("depth") : 
   #   no applicable method for 'depth' applied to an object of class "NULL"

During the crash, the R window goes blank, in the same fashion as when ggplot2 clears the canvas during an plot draw or redraw.

Within RStudio, while I haven't tried it hundreds of times, I can repeat this most of the time:

• just the RSTudio plot window: does not crash;

• both the RStudio plot window and an external windows graphics device: does not crash, but takes longer than normal to redraw

• close the RStudio plot and keep the windows graphics device active: crashes (when disconnecting the second monitor, same general steps as above)

  

While this test uses a second monitor, it has also triggered consistently-enough without a second monitor when transitioning from a sleep/hibernate power state; if the premise of window-dimensions I offered above carries into this, then I believe windows might be altering the desktop geometry to allow the video devices to sleep ... though again, no verification. Testing to/from hibernation takes a lot longer, so I focused on reproducibility with a lot less time-requirement.

R-3.5.3, ggplot2-3.2.0

[r2evans]

I also just installed R-3.6.1 and ggplot2-3.2.1, and the same steps again continue to crash R, so it does not appear to be completely dependent on R < 3.6.

[pmur002]

Based on these descriptions and those in #2514 it sounds like it is related to a (mostly Windows or Mac ?) graphics device being resized or made visible. That would trigger a replay of the graphics engine display list, so this is possibly to do with creating an unstable/corrupt 'grid' state by generating multiple overlapping replays of the graphics engine display list. It could also be specific to how/when the Windows and/or Mac graphics device is triggering replays of the graphics engine display list. If that wild speculation is anywhere near the mark, we are probably dealing with how these graphics devices handle events (like expose events). There is evidence that both Windows and Quartz devices make use of a modal flag (xd->replaying and qd->redraw respectively) to avoid certain activities during a redraw. Perhaps the problem relates to not making use of the modal flag when handling a particular event. This gets complicated and requires both a reproducible example AND a debugging set up on Windows and/or Mac. I do not have the latter at the moment, but may do so by next year, plus will have Simon Urbanek as a neighbour, so may be able to bug him about at least the Mac part :)

[thomasp85]

Good news is that I’ve managed to make a reproducible example. Bad news is that it is on Linux (in relation to your theory) and that I can only trigger it during a knitr build on R 3.5 and below... I’ll update once I know more

[r2evans]

@pmur002, your approach sounds solid, and I'm encouraged that somebody has been able to find a plausible theory for the underlying instability. I hope @thomasp85's knitr-reproducible example can provide some insight, as I know my "reproducibility" is lacking automation. Thanks! (This really is a frustrating bug that strikes without remorse and never at a convenient moment.)

[pmur002]

@thomasp85 , that is nice and reproducible for me, but ONLY for R < 3.6. I believe I have tracked it down to a fix in grid (see doc/changes.txt) ...

Changes from grid_3.5.* to grid_3.6.0:
-------------------------------------
2.  Improve handling of graphics devices in grid.grabExpr().
    Should now work when multiple graphics devices already open
    (e.g., within 'knitr' document).

So unfortunately it seems that that is not the problem we are looking for.

[r2evans]

Frankly, I'm not convinced that this is wholly within ggplot2. The error message

Error: REAL() can only be applied to a 'numeric', not a 'NULL'

to me strongly suggests a C component, which ggplot2 itself doesn't use. Its imports include grid and grDevices, which both use C files and the REAL(...) call. Unfortunately, this error does not provide any traceback information, so there's no easy way to know which call is passing NULL. Since all of my graphics-related crashes have been while using ggplot2, my lean is towards grid (between the two), though there is a lot of REAL(...) in that package (github search).

[pmur002]

I think that it is extremely likely to be in 'grid' - unfortunately, still need a reliable reprex (on Linux) that I can debug.

[pmur002]

I have gained access to a macOS machine - did anyone have a code-based reproducible example that I could try out ?

[joethorley]

library(ggplot2)

for(i in 1:40) {
  print(i)
  gp <- ggplot(data = mtcars, aes(x = wt, y = mpg)) +
    geom_point()
  quartz()
  print(gp)
}
#> [1] 1
#> [1] 2
#> [1] 3
#> Error in UseMethod("depth"): no applicable method for 'depth' applied to an object of class "NULL"

^{Created on 2020-05-11 by the reprex package (v0.3.0)}

[pmur002]

Thanks. That does it for me. Now, let's see if I can see why ...

[pmur002]

I believe I have tracked the source of this problem and, as suspected, it is (in the quartz() case at least) the device triggering a redraw in the middle of drawing (presumably in response to a window event of some sort), which reinitialises the 'grid' system state, including the 'grid' viewport stack, and everything crashes to a halt. So some progress, but I now need to enlist some help from the quartz() device author(s) to try to find a fix.

[r2evans]

Thank you, @pmur002, for doing what I don't have the proficiency to do myself. Thank you.

[pmur002]

Let's wait and see if I have the proficiency :) More likely, Simon Urbanek is going to have the proficiency!

[r2evans]

@pmur002, update: I'm now on R-4.0.2 and ggplot2-3.3.0 (still win10) and while it is much easier now to trigger the response (just mouse over a ggplot graphic window and scroll the mouse wheel), it seems to crash a little less often.

_{Not sure if it helps any, I'm trying to add whatever perspective I can to the problem, hoping somebody will have an "aha!" moment.}

[pmur002]

Just acknowledging the additional reports: thanks guys. Further progress is waiting on myself and/or Simon finding time amongst teaching to take a closer look on a Mac.

[jlederluis]

Hi, just wanted to say that we are having the same problem in our repo and I'm following this closely. Any temporary workarounds are much appreciated!

[yutannihilation]

As we haven't seen any new reports for this two years, I think this can be closed now. Thanks again @pmur002 for fixing this!

[r2evans]

Thank you @yutannihilation and @pmur002 , I have tried several times (R-4.1.2, ggplot2-3.3.5) with my previous example (ggplot, then mouse-wheel like a mad-man), and while I still periodically (though less-frequently) see one of

### most commonly
Error in UseMethod("depth") : 
  no applicable method for 'depth' applied to an object of class "NULL"
### occasionally
Error in grid.Call.graphics(C_upviewport, as.integer(n)) : 
  cannot pop the top-level viewport ('grid' and 'graphics' output mixed?)

I have yet to crash my R. Fantastic!

[shahnawaz323]

I have got this error today on debian linux with grid.arrange by grid package. I am using R on VS code and viewing graphs with httpgd in browser.

  no applicable method for 'depth' applied to an object of class "NULL"```

[tfanatik]

Got this today:
Error in UseMethod("depth") :
no applicable method for 'depth' applied to an object of class "NULL"
from this code:
install.packages("ggcorrplot")
library(ggcorrplot)
model.matrix(~0+., data=killings_df) %>%
cor(use="pairwise.complete.obs", method = "square") %>%
ggcorrplot(show.diag=FALSE, type="lower", lab=TRUE, lab_size=2)

on a Windows10 laptop running R 4.3.1 but working in RStudio

I went thru this whole thing from the beginning and couldn't see how you guys resolved this but I need help too. Thanks!

[tfanatik]

Sorry dudes! I found my error was fixed by adding the method.. the correct method tho! I'm fine, ignore my plea please!

[strengejacke]

I found this error recently after updating to ggplot2 3.5.0. I'm using VSCode on windows 11, latest R version. I guess it could be related to the ggplot2 update, because it now happens with code that used to work fine before.

[teunbrand]

Can you provide a reprex of what used to work but no longer does?

[strengejacke]

I'll try, and if I have one, I would open a new issue.

[sofiabiffi]

I found this error recently after updating to ggplot2 3.5.0. I'm using VSCode on windows 11, latest R version. I guess it could be related to the ggplot2 update, because it now happens with code that used to work fine before.

I am also in this exact situation since the latest update, the first couple plots I run in a new session work and then I get the depth issue error and the plots appear completely misdrawn

[teunbrand]

Paul Murrell previously traced a very similar error to issues with the graphics device. I'm not sure what graphics device VSCode uses, but seems likely that the error orginates there.

[sofiabiffi]

Paul Murrell previously traced a very similar error to issues with the graphics device. I'm not sure what graphics device VSCode uses, but seems likely that the error originates there.

Ah I see, I'll dig deeper then. Thank you so much