You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue seems to be when 'idcol' is used and there are empty data.tables in the list to be rbind'ed. I found the following workaround seems to produce the expected behaviour:
*.RDS and *.RData are file types which can store in-memory R objects on disk efficiently. However, storing data.table into the binary file loses its column over-allocation. This isn't a big deal -- your data.table will be copied in memory on the next by reference operation and throw a warning. Therefore it is recommended to call alloc.col() on each data.table loaded with readRDS() or load() calls.
Does rbindlist(lapply(test, alloc.col), idcol = "tid") also crash?
sessionInfo()
# R version 3.4.1 (2017-06-30)
# Platform: x86_64-apple-darwin15.6.0 (64-bit)
# Running under: OS X El Capitan 10.11.6
library("data.table")
# data.table 1.10.4
Just got caught with this as well. Here's a simpler example... Run it a couple of times to get a segfault (on Windows with 1.10.4 at the moment):
require(data.table)
ll<-list(data.table(x=1, y=2), data.table(), data.table(x=3, y=4))
dt<- data.table(bla=1:3, ll)
# run multiple times and you should get a segfault)dt[, rbindlist(ll, idcol=".id")]
dt[, rbindlist(ll, idcol=".id")]
dt[, rbindlist(ll, idcol=".id")]
dt[, rbindlist(ll, idcol=".id")]
I'm not sure this is related only to the use of idcol. I'm getting it with some real world data, but I don't have a replicable use case. My setup reads 1000 data.tables from disk (in 1000 rds files), selects some rows and aggregates, and then rbinds the results.
(Actually, 40 files are read from disk and the selection and aggregation are applied, with rbindlist called on that result which is stored in a list via lapply. then rbindlist is called again on the resulting list. this is result of that process.)
I've verified that all items in the list are of class data.table, and have nonzero number of rows. The list is 30.1 GB as reported by pryr::object_size on a machine with 1.5 TB of RAM
uscd = rbindlist(user_song_count_dtlist)
*** caught segfault ***
address 0x7f27442b92c4, cause 'memory not mapped'
Traceback:
1: rbindlist(user_song_count_dtlist)
(sorry for the delete/repost, wanted to use this account, edit on reading from disk turned out to be inaccurate)
apologies, after attempting some workarounds, I've discovered that it seems as if a data.table can't have more than MAXINT rows. Didn't realize that was a limitation and is probably what was causing my issue
@jsams Given the above, I doubt it's related to MAXINT in your case. Can you confirm dev works fine for you? But MAXINT is a good side issue. The rbindlist.c source accumulates n_rows in type size_t so that looks correct and won't overflow but I can't see a check that n_rows < MAXINT. A test could construct a list() with multiple references to the same DT so that the "big" test will run and test it fails gracefully (that the result would be > 2bn rows) without actually needing a lot of RAM to run. [Update: yes there was a segfault there. Fixed and test added.]
Activity
franknarf1 commentedon Sep 7, 2017
The FAQ,
vignette("datatable-faq")saysDoes
rbindlist(lapply(test, alloc.col), idcol = "tid")also crash?peekxc commentedon Sep 7, 2017
Hmm I did not notice this in the FAQ. That being said, it does still crash the session.
franknarf1 commentedon Sep 7, 2017
Oh, hadn't noticed your example was in a gist. No repro here on R 3.3.3:
Btw, I guess you are testing on the devel version. If not, see https://github.com/Rdatatable/data.table/wiki/Support
peekxc commentedon Sep 7, 2017
Interesting that it doesn't seem to reproduce.
I don't think I'm using a dev version?
arunsrinivasan commentedon Sep 20, 2017
Just got caught with this as well. Here's a simpler example... Run it a couple of times to get a segfault (on Windows with 1.10.4 at the moment):
jsams commentedon Sep 21, 2017
I'm not sure this is related only to the use of idcol. I'm getting it with some real world data, but I don't have a replicable use case. My setup reads 1000 data.tables from disk (in 1000 rds files), selects some rows and aggregates, and then rbinds the results.
(Actually, 40 files are read from disk and the selection and aggregation are applied, with rbindlist called on that result which is stored in a list via lapply. then rbindlist is called again on the resulting list. this is result of that process.)
I've verified that all items in the list are of class data.table, and have nonzero number of rows. The list is 30.1 GB as reported by pryr::object_size on a machine with 1.5 TB of RAM
*** caught segfault ***
address 0x7f27442b92c4, cause 'memory not mapped'
Traceback:
1: rbindlist(user_song_count_dtlist)
(sorry for the delete/repost, wanted to use this account, edit on reading from disk turned out to be inaccurate)
jsams commentedon Sep 22, 2017
apologies, after attempting some workarounds, I've discovered that it seems as if a data.table can't have more than MAXINT rows. Didn't realize that was a limitation and is probably what was causing my issue
mattdowle commentedon Nov 8, 2017
I can reproduce using @arunsrinivasan's example with current CRAN (1.10.4-3) on Ubuntu.
It looks fixed in dev though. Bug fix 5 in news for 1.10.5 :
Thanks to @mllg's PR #2077 merged in May 2017.
@jsams Given the above, I doubt it's related to MAXINT in your case. Can you confirm dev works fine for you? But MAXINT is a good side issue. The
rbindlist.csource accumulatesn_rowsin typesize_tso that looks correct and won't overflow but I can't see a check thatn_rows < MAXINT. A test could construct alist()with multiple references to the sameDTso that the "big" test will run and test it fails gracefully (that the result would be > 2bn rows) without actually needing a lot of RAM to run. [Update: yes there was a segfault there. Fixed and test added.]Tidied format specifier from %lld to %d in rbindlist error message, #…