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.

[joethorley]

I'm getting the same error with R 4.0.0. It's so frequent this morning that I all 20+ attempts to rerun a script to produce some plots have failed...

A traceback is

17: upViewport(depth(vp), recording = FALSE)
16: popgrobvp.viewport(x$vp)
15: popgrobvp(x$vp)
14: postDraw.grob(x)
13: postDraw(x)
12: drawGTree(x)
11: recordGraphics(drawGTree(x), list(x = x), getNamespace("grid"))
10: grid.draw.gTree(x$children[[i]], recording = FALSE)
9: NextMethod()
8: grid.draw.absoluteGrob(x$children[[i]], recording = FALSE)
7: grid.draw(x$children[[i]], recording = FALSE)
6: drawGTree(x)
5: recordGraphics(drawGTree(x), list(x = x), getNamespace("grid"))
4: grid.draw.gTree(gtable)
3: grid.draw(gtable)
2: print.ggplot(gp)
1: print(gp)```