I have installed R on my windows server 2019 and installed Rcpp package, then compressed its installation to a zip file (R-4.0.2.zip).
In a C++ application on another machine, I decompress this R-4.0.2.zip, set R_HOME and PATH to point to the extracted directory and /bin/x64, respectively. I then load R.dll to run a simple R script.
I have run this application on my machine using the extracted R-4.0.2.zip and also another machine with no pre-installation of R where I have access to its graphical user interface. However, when I run it on another machine (server), which I don't have access to its graphical interface, the R suicides itself with a message in a messagebox (that I can only see with a windows debugger from its dump).
Fatal error: unable to initialize the JIT
user32!SoftModalMessageBox+0x228b [d:\xx\windows\core\ntuser\client\msgbox.c # 1235]
user32!MessageBoxWorker+0x2ec [d:\xx\windows\core\ntuser\client\msgbox.c # 782]
user32!MessageBoxTimeoutW+0xd5 [d:\xx\windows\core\ntuser\client\msgbox.c # 439]
user32!MessageBoxTimeoutA+0x102 [d:\xx\windows\core\ntuser\client\msgbox.c # 483]
user32!MessageBoxExA+0x10 [d:\xx\windows\core\ntuser\client\msgbox.c # 369]
user32!MessageBoxA+0x4e [d:\xx\windows\core\ntuser\client\msgbox.c # 342]
R!R_Suicide+0x39
R!setup_Rmainloop+0x954
Any idea what could be the potential problem for this? do I need to install a specific package such as Rserve, any specific firewall rule? [the CPP application and R script run on the same machine though]
Related
I'm using the package RSAP to read SAP data.
RSAP loads a SNC (Secure Network Connection) dynamic library and searching for it with the environment variable SNC_LIB.
Depending on the local user system, this might be a 32 or 64 bit library.
I'm setting the environment variable within my R script.
But RSAP still search in the old path.
I try to avoid setting the environment variable outside by application because it's a shiny app which should be used by many users.
It seems that the environment variable is changed only within the RSTUDIO session but not outside.
Initial situation of the environment variables within RStudio console:
> Sys.getenv("SNC_LIB_64")
[1] "C:\\Program Files\\SAP\\FrontEnd\\SecureLogin\\lib\\sapcrypto.dll"
> Sys.getenv("SNC_LIB")
[1] "C:\\Program Files (x86)\\SAP\\FrontEnd\\SecureLogin\\lib\\sapcrypto.dll"
Coding:
# check SNC_LIB path from environment variables
# 32 or 64 bit?
# if 64 bit lib path is set, set the default lib path variable
# SNC_LIB to it
lib_path_64 <- Sys.getenv("SNC_LIB_64")
if (lib_path_64 != "") {
Sys.setenv("SNC_LIB" = lib_path_64)
}
After the code is executed in RStudio debugger:
Browse[2]> Sys.getenv("SNC_LIB")
[1] "C:\\Program Files\\SAP\\FrontEnd\\SecureLogin\\lib\\sapcrypto.dll"
Error thrown by RSAP on loading the library:
[Thr 12160] Wed Jan 03 17:42:57 2018
[Thr 12160] *** ERROR => SncPDLInit()==SNCERR_INIT, Adapter #1 (C:\Program Files (x86)\SAP\FrontEnd\SecureLogin\lib\sapcrypto.dll) not loaded [sncxxdl.c 727]
Old path is used. When I change the path outside before running RStudio it's working.
Question:
Is there a way to set the library path variable SNC_LIB in another way to be sure is globally and not locally changed and RSAP dynamic loading is working well?
Easy way to reproduce is:
Start RStudio
Call Sys.setenv("TEST_VAR" = "good")
Call Sys.getenv("TEST_VAR")
See right result [1] "good"
Close RStudio
Start RStudio again
Call again Sys.getenv("TEST_VAR")
See 'wrong' unexpected result [1] ""
Environment variables set in R affect that process and processes it runs, they don't persist when R quits.
It's not clear what steps you took to lead to your RSAP error, but your "easy code to reproduce" script is acting as expected.
The only way a Sys.setenv() in an R session will affect a subsequent library load is if that load is happening in the R session (e.g. loading an R package that loads the library) or in a process R launches (e.g. running a command using system()).
This is the error message:
> h2o.init()
Error in dirname(path) : path too long
In addition: There were 12 warnings (use warnings() to see them)
This is one of the warning messages (the others are similar):
> warnings()
Warning messages:
1: In normalizePath(path.expand(path), winslash, mustWork) :
path[1]="\\FILE-EM1-06/USERDATA2$/john134/My Documents/./../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../..": The filename or extension is too long
Any idea how to work around this error?
Thanks
It seems that Windows path string is limited to (maybe) 256 length. Usually, setting a the path setwd(shorterExistingWorkDir) works and should address your issue.
I struggled with this issue quite a bit, including upgrading.
Most folks are assuming that you've literally just set an incredibly long path. I don't think this is the case (it wasn't for me, at least). It's that the PATH may be set on a network drive or other device where the underlying mapped paths are more complicated.
A related thread is here on the H2O forum:
Main issue is the user had a Windows drive that did not conform to the norm, i.e., "C://", etc. Instead, the user had a network drive
(DTCHYB-AZPX015/). This caused issues in the search for a config
file as there was no "root" (In this case, "root" is reaching your Win
drive). Since there was no "root", the path to search kept expanding
until it caused R to error out with the above exception.
The fix is to NOT search for a config when h2o.init() is called. Rather, only search for a config if a user asks to do so. My proposal
is to add a new field to h2o.init()called ignore_config. This
field will be set to TRUE by default.
When calling h2o.init() the R environment signal the launching of h2o application (actually a web server) in the backend which was installed when you install H2O package into R. The local runtime environment uses the full path of the location where H2O jar file is located. Because the packages is installed deep inside the nested folders in your file system it cross the valid limit of OS path 256 character length and fails to launch the backend H2O server and you see this error. In your case you are using external path so adds up more characters in the path to make the problem worse..
For example the h2o.jar is located in my OSX machine as below:
/Library/Frameworks/R.framework/Resources/library/h2o <-- H2O package Path
/Library/Frameworks/R.framework/Resources/library/h2o/java/h2o.jar <-- Jar Path
As you are using Windows, what you need is to find ways to reduce this path to OS limit and it will work.
The other solution is to run h2o.jar separately and then just use R to connect to H2O cluster. The steps are as below:
Download H2O 3.10.4.2 and unzip to a folder close to root so you do not hit 265 char limit again. Also install 3.10.4.2 R Package. (Try to keep the same version)
Run H2O > java -jar h2o.jar
From RStudio console try > h2o.init()
So if there is already H2O cluster running the h2o.init() will connect to a running H2O cluster instead to start one and you will by pass above problem.
If you hit any problem write here and we will help you.
This is the first time I have tried to connect R and Tableau.
I have downloaded and installed Rserve successfully but every time I try to start Rserve is get this warning:
Starting Rserve...
"C:\Users\SIMON~1.HAR\DOCUME~1\R\WIN-LI~1\3.1\Rserve\libs\x64\Rserve.exe"
Warning message:
running command '"C:\Users\SIMON~1.HAR\DOCUME~1\R\WIN-LI~1\3.1\Rserve\libs\x64\Rserve.exe" ' had status 127
I have been searching for days and couldn't find any fix.
The Rserve() function is trying to start an application (Rserve.exe) and failed. There's a couple of things you can do.
Go to the "C:\Users\SIMON~1.HAR\DOCUME~1\R\WIN-LI~1\3.1\Rserve\libs\x64\" file directory and try loading the exe yourself, troubleshoot from there.
use the run.Rserve() function instead of Rserve(). This will use your current R session to start the Rserve server. This means the exe doesn't need to be run. This worked well for me because I am working in an environment where I don't enough privileges to run the exe. It does mean that your R session can't do anything else while the server is running, but you can always load up 2 sessions at the same time.
I'm running into an issue when building the following package: https://github.com/yoni/rbundler
My test attempts to run rbundler's bundle command on a trivial package which has a single dependency. The test passes on my OSX machine, but fails on my x86_64-redhat-linux-gnu Jenkins server. Both machines are running R 2.15.1 with devtools 0.7.1, which includes this bug fix.
The full test output can be found in this gist.
Here's a short summary of error I'm seeing:
Error in file(filename, "r", encoding = encoding) :
cannot open the connection
Calls: local ... eval.parent -> eval -> eval -> eval -> eval -> source -> file
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
cannot open file 'startup.Rs': No such file or directory
Execution halted
The background for this is that I'm trying to build a dependency management system for R. The idea is that an R project should be able to run without using system-wide or user-wide libraries. Rather, the R project will have it's own library installed under it's root directory.
For my previous Stack Overflow question related to Dependency Management in R, see Dependency management in R
In my case this issue was caused by the environment variable R_TESTS that was set to startup.Rs
When you execute another R process from within your tests (in my case it was submitted via OGS qsub), the presence of this environment variable causes issues.
I can't answer your question directly, but two things you can try get more information about what is happening.
use 'env' to dump environment variables on your OSX machine and the Jenkins host
run the process through strace on Linux and dtruss on OSX to trap the system calls
strace/dtruss should reveal the places in which it is searching for startup.Rs and env output will likely give you a environment variable that differs between the system accounting for the different outcome.
I am using the JRI api to use "R" in Java. I have created a web-service which has the JRI code . When I consume this web-service for the first time it works properly, but with a subsequent request the JVM crashes and says : "The crash happened outside the Java Virtual Machine in native code."
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (0xc0000029), pid=9148, tid=9716
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) Client VM (20.1-b02 mixed mode windows-x86 )
# Problematic frame:
# C [ntdll.dll+0x8e1b9]
#
# An error report file with more information is saved as:
# C:\Users\ambarish\.netbeans\dev\config\GF3\domain1\hs_err_pid9148.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Is this somehow connected to the fact that R has no threading support, you can run only one instance of R within a multi-threaded application?
I am using Rengine to run R scripts in Java, I tried to stop/destroy the Rengine object but it did not work. How can I make sure that Rengine instance is garbage-collected before the second request.
Please let me know how can I solve this issue.
One can only create a single instance of Rengine using JRI. So use Rserve instead, which supports threading.