readChangeoDb failed in sbatch mode on Farnam
*** caught illegal operation ***
address 0x2ac521618728, cause 'illegal operand'
Traceback:
1: .Call("readr_guess_header_", PACKAGE = "readr", sourceSpec, tokenizerSpec, locale_)
2: guess_header_(datasource, tokenizer, locale)
3: guess_header(ds_header, tokenizer, locale)
4: col_spec_standardise(data, skip = skip, comment = comment, guess_max = guess_max, col_names = col_names, col_types = col_types, tokenizer = tokenizer, locale = locale)
5: read_delimited(file, tokenizer, col_names = col_names, col_types = col_types, locale = locale, skip = skip, comment = comment, n_max = n_max, guess_max = guess_max, progress = progress)
6: readr::read_tsv(file, na = c("", "NA", "None"))
7: withCallingHandlers(expr, message = function(c) invokeRestart("muffleMessage"))
8: suppressMessages(readr::read_tsv(file, na = c("", "NA", "None")))
9: readChangeoDb(paste0("d", d, "_14_cat.tab"))
An irrecoverable exception occurred. R is aborting now ...
/var/spool/slurmd/job1509736/slurm_script: line 14: 39668 Illegal instruction
Solution: use base R
read.table("changeoDb.tab", sep="\t", header=T, stringsAsFactors=F)
Comments (6)
-
-
reporter Welp, remember that one time we tried numerous things including changing GCC versions on Farnam and nothing worked? That was for mutate_at/each from dplyr, but I suspect the same thing won't for readr either..
-
Yeah, I'm sure you're right. It stands to reason we'll have this problem with dplyr in general using sbatch.
-
reporter Ergh last time I was able to work around to the problem by running interactive instead of sbatch, but now it fails in interactive mode too :/ #freakingout
-
No bueno. I'll test tomorrow. See if I can figure it out.
-
- changed status to resolved
Apparently, we need to compile tidyverse packages on the m915 node or they won't work on the m915 node. See the
Problematic R package compilation
section of the cluster wiki:
https://bitbucket.org/kleinstein/immcantation/wiki/ClusterConfig - Log in to comment
So... We can't switch to base R for performance reasons (see
#39). Hrm. I wonder if this is GCC related?