R session abort when I use assignTaxonomy - r

I have been having this problem for more than a week now and I am running out of time and patience.This problem occurs when I run my script on a Mac and when I run it on a PC (no difference of results from more RAM, it just aborts faster). When I try to run this line of my dataset, the session aborts.
set.seed(119)
tax_PR2 <- assignTaxonomy(seqtab,
"~/Desktop/Documents/Bruts/aeDNA_data_shared/pr2_version_4.11.1_dada2.fasta",
multithread=TRUE)
Does anyone have any idea of what the problem is? I verified my dataset (seqtab is currently considered by R as a large matrix of 3930724 elements of 20.2Mb), I verified the space I have on my computer, I have all the needed packages to run this line of code and I tried different sources of genome database for PR2 (PR2 version 4.11.1 or 4.12.0 etc...) and it always has the same result.
If you have any ideas I would appreciate them. I hope the information I gave is sufficient.
Packages installed:
library(BiocManager)
library(Rcpp)
library(dada2)
library(ff)
library(ggplot)
library(gridExtra)
library(phyloseq)
library(vegan)

This is probably caused by a bug that was introduced in 1.14, see the Github issue here for more information: https://github.com/benjjneb/dada2/issues/916
We've just identified the cause, and a fix should be out soon. For immediate use, the workaround is to turn off multithreading, or to revert to the previous release 1.12.

Related

devtools::check generates an error (install options '--no-html --no-multiarch) at seemingly randomly times

I am creating my own package and use devtools to document and check the package. About 50% of the time that I run devtools::check() it ends with this error:
❯ checking whether package 'snafun' can be installed ... ERROR See below...
── Install failure ─────────────────────────────────────────────────────────────────────────────────────────────────
install options '--no-html --no-multiarch
However, this only happens about half the time. Sometimes it doesn't and sometimes it does. I can run devtools::check several times in a row (without making any change to the code or the session in between) and get this error on half of the runs, and on the other half not. And sometimes it seems to help if I restart the session in between an other times it makes no difference.
I have tried playing with the arguments of devtools::check, but that doesn;t seem to affect the error (which could be related to this being an "Install failure" and devtools::check doesn't have install arguments).
I am puzzled. I have the following questions:
what does this error even mean? Is it problematic?
what can make it occur and disappear seemingly randomly?
what might be a direction to solve this?
ps the package is quite large, so I can't really turn this into a reprex
I got exactly the same problem and I solved it installing the rcmdcheck package.
install.packages("rcmdcheck")
library(rcmdcheck)
rcmdcheck('MyPath/MyPackage')

Running R code on linux in parallel on computing cluster

I've recently converted my windows R code to a Linux installation for running DEoptim on a function. On my windows system it all worked fine using:
ans <- DEoptim1(Calibrate,lower,upper,
DEoptim.control(trace=TRUE,parallelType=1,parVAr=parVarnames3,
packages=c("hydromad","maptools","compiler","tcltk","raster")))
where the function 'Calibrate' consisted of multiple functions. On the windows system I simply downloaded the various packages needed into the R library. The option paralleType=1 ran the code across a series of cores.
However, now I want to put this code onto a Linux based computing cluster - the function 'Calibrate' works fine when stand alone, as does DEoptim if I want to run the code on one core. However, when I specify the parelleType=1, the code fails and returns:
Error in checkForRemoteErrors(lapply(cl, recvResult)) :
7 nodes produced errors; first error: there is no package called ‘raster’
This error is reproduced whatever package I try and recall, even though the
library(raster)
command worked fine and 'raster' is clearly shown as okay when I call all the libraries using:
library()
So, my gut feeling is, is that even though all the packages and libraries are loaded okay, it is because I have used a personal library and the packages element of DEoptim.control is looking in a different space. An example of how the packages were installed is below:
install.packages("/home/antony/R/Pkges/raster_2.4-15.tar.gz",rpeo=NULL,target="source",lib="/home/antony/R/library")
I also set the lib paths option as below:
.libPaths('/home/antony/R/library')
Has anybody any idea of what I am doing wrong and how to set the 'packages' option in DEoptim control so I can run DEoptim across multiple cores in parallel?
Many thanks, Antony

Error in fetch(key) : lazy-load database

I don't know what is going on, everything was working great but suddenly I started to have this error message on the documentation:
Error in fetch(key) : lazy-load database '......descopl.rdb' is
corrupt
I removed almost all my code and build again then publish to Github, but when I use the other laptop to download the package, the package is being downloaded and loaded but I can't call any of the functions, and the documentation states that error.
I don't know what caused the problem, I am using roxygen to generate the documentation.
https://github.com/WilliamKinaan/descopl
It seems that the error arises when the package cannot be decompressed by R (as #rawr established, it is corrupt). This solutions have worked for me:
1) Check for possible errors in the creation of the .Rdb files
2) Try restarting your R session (e.g. .rs.restartR() if in RStudio)
3) The package might have been installed in your computer (even though it does not work). Remove it using ?remove.packages()
I have had this problem with roxygen2 as well. Couldn't see any problem with any of my functions. In the end deleting the .rdb file and then getting roxygen2 to rebuild it seemed to solve the problem.
I think the explanation for what is causing this is here.
It's related to devtools.
Per #Zfunk
cd ~/Rlibs/descopl/help
rm *.rdb
Restart R. Look at the help for the package again. Fixed!
I received this error after re-installing a library whilst another R session was running.
Simply restarting the existing R session(s) solved for me (i.e. running .rs.restartR() to restart the sessions)
If you are using R-studio:
1) ctrl+shift+f10 to restart r session
2) tools -> Check for package updates -> update all packages
3) library(ggmap)
Problem is solved.
Basically all answers require restarting R to resolve the issue, but I found myself in an environment where I really didn't want to restart R.
I am posting here a somewhat hack-ish solution suggested by Jim Hester in a bug report about the lazy-load corruption issue.
The gist of it is that the package may have some vestigial S3 methods listed in session's .__S3MethodsTable__. environment. I don't have a very systematic way of identifying which S3 methods in that environment come from where, but I think a good place to start is the print methods, and looking for S3method registrations in the package's NAMESPACE.
You can then remove those S3 methods from the .__S3MethodsTable__. environment and try again, e.g.
rm(list="print.object", envir = get(".__S3MethodsTable__.", envir = baseenv()))
You may also need to unload some DLLs if some new messages come up like
no such symbol glue_ in package /usr/local/lib/R/site-library/glue/libs/glue.so
You can check getLoadedDLLs() to see which such files are loaded in your session. In the case of glue here, the following resolved the issue:
library.dynam.unload('glue', '/usr/local/lib/R/site-library/glue')
I got this error on RStudio on mac OS - updating all the packages and restarting r session did the trick.

How to crash R?

Is there a simple way to trigger a crash in R? This is for testing purposes only, to see how a certain program that uses R in the background reacts to a crash and help determine if some rare problems are due to crashes or not.
The easiest way is to call C-code. C provides a standard function abort()[1] that does what you want. You need to call: .Call("abort").
As #Phillip pointed out you may need to load libc via:
on Linux, dyn.load("/lib/x86_64-linux-gnu/libc.so.6") before issuing .Call("abort"). The path may of course vary depending on your system.
on OS X, dyn.load("/usr/lib/libc.dylib")
on Windows (I just tested it on XP as I could not get hold of a newer version.) you will need to install Rtools[2]. After that you should load dyn.load("C:/.../Rtools/bin/cygwin1.dll").
There is an entire package on GitHub dedicated to this:
crash
R package that purposely crash an R session. WARNING: intended
for test.
How to install a package from github is covered in other questions.
I'm going to steal an idea from #Spacedman, but I'm giving him full conceptual credit by copying from his Twitter feed:
Segfault #rstats in one easy step:
options(device=function(){});plot(1)
reported Danger, will crash your R session.
— Barry Rowlingson (#geospacedman) July 16, 2014
As mentioned in a comment to your question, the minimal approach is a simple call to the system function abort(). One way to do this in one line is to
R> Rcpp::cppFunction('int crashMe(int ignored) { ::abort(); }');
R> crashMe(123)
Aborted (core dumped)
$
or you can use the inline package:
R> library(inline)
R> crashMe <- cfunction(body="::abort();")
R> crashMe()
Aborted (core dumped)
$
You can of course also do this outside of Rcpp or inline, but then you need to deal with the system-dependent ways of compiling, linking and loading.
I'll do this in plain C because my C++-foo isn't Dirkian:
Create a C file, segv.c:
#include <signal.h>
void crashme(){raise(SIGSEGV);}
Compile it at the command line (windows users will have to work this out for themselves):
R CMD SHLIB segv.c
In R, load and run:
dyn.load("segv.so") # or possibly .dll for Windows users
.C("crashme")
Producing a segfault:
> .C("crashme")
*** caught segfault ***
address 0x1d9e, cause 'unknown'
Traceback:
1: .C("crashme")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault
This is the same behaviour as the one Thomas references in the graphics system bug report which I have filed and might get fixed one day. However this two-liner will always raise a segfault...
Maybe Dirk can one-line-Rcpp-ise it?
If you want to crash your R, try this
lapply("", function(x) eval(sys.call(1)))
(Save everything before running because this immediately results in "R Session Aborted")
Edit: This works for me on Windows 10.

Unexpected behavior of R after install on another EC2 instance

I'm fighting this problem second day straight with a completely sleepless night and I'm really starting to lose my patience and strength. It all started after I decided to provision another (paid) AWS EC2 instance in order to test my R code for dissertation data analysis. Previously I was using a single free tier t1.micro instance, which is painfully slow, especially when testing/running particular code. Time is much more valuable than reasonable number of cents per hour that Amazon is charging.
Therefore, I provisioned a m3.large instance, which I hope should have enough power to crunch my data comfortably fast. After EC2-specific setup, which included selecting Ubuntu 14.04 LTS as an operating system and some security setup, I installed R and RStudio Server per instructions via sudo apt-get install r-base r-base-dev as ubuntu user. I also created ruser as a special user for running R sessions. Basically, the same procedure as on the smaller instance.
Current situation is that any command that I issuing in R session command line result in messages like this: Error: could not find function "sessionInfo". The only function that works is q(). I suspect here a permissions problem, however, I'm not sure how to approach investigating permission-related problems in R environment. I'm also curious what could be the reasons for such situation, considering that I was following recommendations from R Project and RStudio sources.
I was able to pinpoint the place that I think caused all that horror - it was just a small configuration file "/etc/R/Rprofile.site", which I have previously updated with directives borrowed from R experts' posts here on StackOverflow. After removing questionable contents, I was able to run R commands successfully. Out of curiosity and for sharing this hard-earned knowledge, here's the removed contents:
local({
# add DISS_FLOSS_PKGS to the default packages, set a CRAN mirror
DISS_FLOSS_PKGS <- c("RCurl", "digest", "jsonlite",
"stringr", "XML", "plyr")
#old <- getOption("defaultPackages")
r <- getOption("repos")
r["CRAN"] <- "http://cran.us.r-project.org"
#options(defaultPackages = c(old, DISS_FLOSS_PKGS), repos = r)
options(defaultPackages = DISS_FLOSS_PKGS, repos = r)
#lapply(list(DISS_FLOSS_PKGS), function() library)
library(RCurl)
library(digest)
library(jsonlite)
library(stringr)
library(XML)
library(plyr)
})
Any comments on this will be appreciated!

Resources