I found this bug after I freshly installed the newest available versions of R, RStudio, data.table, and dplyr on a new Mac. I tried to run a simple script that worked on my old computer and ran into this bug. It seemed to happen somewhat unpredictably after running several lines of dplyr, with a session restart occasionally fixing it but only temporarily. Once the bug had "hit" a specific object, the error occurred on any interaction with that object afterwards including RStudio View() and printing the object to the console. I'm a novice but I worked with a friend to create this reproducible example which will hopefully work on other computers. In my actual script, the bug did not always occur in the same part of the code.
Minimal reproducible example
library(dplyr)
library(data.table)
exp <-
structure(list(a = 1L, b = 1L, c = 1L, d = 1L, e = 1L, f = 1L, g = 1L, h = 1L, i = 1L, j = 1L, k = 1L, l = 1L, m = 1L, n = 1L, o = 1L, p = 1L, q = 1L, r = 1L, s = 1L, t = 1L, u = 1L, v = 1L, w = 1L, x = 1L, y = 1L, z = 1L,
aa = 1L, ab = 1L, ac = 1L, ad = 1L, ae = 1L, af = 1L, ag = 1L, ah = 1L, ai = 1L, aj = 1L, ak = 1L, al = 1L, am = 1L, an = 1L, ao = 1L, ap = 1L, aq = 1L, ar = 1L, as = 1L, at = 1L, au = 1L, av = 1L, aw = 1L, ax = 1L, ay = 1L, az = 1L,
ba = 1L, bb = 1L, bc = 1L, bd = 1L, be = 1L, bf = 1L, bg = 1L, bh = 1L, bi = 1L, bj = 1L, bk = 1L, bl = 1L, bm = 1L), class = "data.frame", row.names = c(NA, -1L))
expadj <- as.data.table(exp)
expadj <- expadj %>% mutate(a = 11) # overwrite preexisting column (??) (doesn't seem to matter which?)
expadj$NewColumn <- expadj$b
# fails here with error "Error in setalloccol(y) : can't set ALTREP truelength"
It seems possibly similar to #2990 or #3051 and in my case seems related to having at least 64 columns before the dplyr line. Changing the existing column without using dplyr prevents the bug from occurring.
Output of sessionInfo()
R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.7
Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] data.table_1.13.0 dplyr_1.0.2
loaded via a namespace (and not attached):
[1] crayon_1.3.4 R6_2.4.1 lifecycle_0.2.0 magrittr_1.5
[5] pillar_1.4.6 rlang_0.4.7 rstudioapi_0.11 vctrs_0.3.4
[9] generics_0.0.2 ellipsis_0.3.1 tools_4.0.2 glue_1.4.2
[13] purrr_0.3.4 compiler_4.0.2 pkgconfig_2.0.3 tidyselect_1.1.0
[17] tibble_3.0.3
I found this bug after I freshly installed the newest available versions of R, RStudio, data.table, and dplyr on a new Mac. I tried to run a simple script that worked on my old computer and ran into this bug. It seemed to happen somewhat unpredictably after running several lines of dplyr, with a session restart occasionally fixing it but only temporarily. Once the bug had "hit" a specific object, the error occurred on any interaction with that object afterwards including RStudio View() and printing the object to the console. I'm a novice but I worked with a friend to create this reproducible example which will hopefully work on other computers. In my actual script, the bug did not always occur in the same part of the code.
Minimal reproducible example
It seems possibly similar to #2990 or #3051 and in my case seems related to having at least 64 columns before the dplyr line. Changing the existing column without using dplyr prevents the bug from occurring.
Output of sessionInfo()