Closed billdenney closed 4 years ago
Yeah, I sometimes get something like this as well when a large ggplot
fails and the whole data.frame/environment is saved in the error report. I have not tested the latest version in which this is solved or mitigated, still running 7.12.0.
@vkehayas , tl;dr: Updating may fix your issue.
In #1253, it was discussed that this may be fixed in 7.12.2, but my instance of this still occurs here. For my case, it may not be a bug directly, but it may be a bottleneck for trying again in these scenarios.
This definitely sounds like #1253, which I thought I fixed. Traceback objects should no longer contain strange tagalong environments. However, there could still be another stowaway in the metadata list. How big is the list you get from diagnose(target_that_failed)
? If it's bigger than a couple kilobytes, what is the inner-most large object you can find with pryr::object_size()
.
I watched the memory use during the process, and here is what I noticed:
Quitting from lines 1627-1767 (filename.Rmd)
x fail report
When the words "x fail report" showed up on the screen, memory usage went from ~2GB to ~5GB over the course of a few seconds.
I then saw the following message:
Error: target report failed.
diagnose(report)error$message:
Problem with mutate()
input figures
.
x Input figures
must be a vector, not a gg_list
object.
i Input figures
is as_gg_list(...)
.
(And some other stuff indicating the stack trace as normally shows up.)
When I run `pryr::object_size(diagnose(report))`, it is 1.28GB. As that is bigger than a couple kb, I investigated further. I'm showing the nesting of the object that I found:
diagnose(report): 1.28GB $error: 1.28 GB $dots: 1.28 GB $figures: 1.28 GB $captions 1.28 GB (yes, both of these are showing up as 1.28 GB after the parent showed up as the same size)
Oddly, the items within `diagnose(report)$error$dots$figures` (and `$captions`) are 56 B and 3.54 kB, not the 1.28 GB that the containing objects were. Both of these items are quosures. I can share what one looks like:
```r
> diagnose(report)$error$dots$figures
<quosure>
expr: ^as_gg_list(pmap(.l = list(data = data, parameter = Parameter, assay = assay, allo_cl = allo_CL, allo_vc = allo_VC), .f = plotter, hline_values = adult_lines))
env: 0000023B83FA2408
It looks like the problem is the environment attached to the quosure:
> pryr::object_size(rlang::get_env(diagnose(report)$error$dots$figures))
1.28 GB
Try 2295fc97fe35c0ceab8f56d1775c508aceb147d0. I gave up on language objects and decided to just have drake
store tracebacks as character vectors. That ought to do it.
Wait, I just realized the traceback isn't the problem like it was for #1253. We'll have to cull the error
object in other ways too.
Try adcefba554cbde08fccf76ae63879bd753cdf74d. That dots
object shouldn't show up in the error
object as of https://github.com/ropensci/drake/commit/af2bbbf04003005d8e2da2908a6c0e4be7be34da.
adcefba fixes it for me!
After x fail report
, there was no memory usage increase like there was last time. pryr::object_size(diagnose(report))
is 25.8 kB.
Great! Closing.
Prework
drake
's code of conduct.remotes::install_github("ropensci/drake")
) and mention the SHA-1 hash of the Git commit you install.Description
I have an issue that may be identical to #1253. Unfortunately, I can't share the example as it is proprietary (and much like you, COVID-related work takes the time I would usually take to try to create a reprex).
Describe the bug clearly and concisely.
It comes up for me, when I'm building a relatively large plan for me (the .drake directory is ~2.6GB). At the point of using rmarkdown to build a report where much of the cache will be loaded, there was a bug in the report causing an error.
After that error, I got "Repacking large object".
When I corrected the error, it ran without issue, and there was no "repacking large object".
My guess is that I'm having the same type of issue as in #1253. I'm running drake 7.12.2.
Reproducible example
Unfortunately, I can't readily make a reprex right now. My hope is that the description above and the link to #1253 will help with some troubleshooting.
Expected result
A quick error message.
As a thought from reading #1253, it seems like the stack trace from errors along with their environments are being stored, and that could be my issue. For errors, could the default behavior be not to store the environments associated with the error?
Session info