Skip to content

R 4.0.2 64-bit Windows hangs

2 messages · m17hpj+bt626qpx8w70w m@iii@g oii guerriii@m@ii@com, Tomas Kalibera

For some further information, on compiling with rtools, using the following scripts, https://github.com/r-windows/r-base, I receive a segfault:


installing 'sysdata.rda'
building package 'compiler'
byte-compiling package 'compiler'
byte-compiling package 'base'
byte-compiling package 'tools'
sh: line 3:  3614 Done                    ( cat ./R/makeLazyLoad.R; echo "makeLazyLoading(\"tools\")" )
      3615 Segmentation fault      | _R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 R_DEFAULT_PACKAGES=NULL LC_ALL=C R_ENABLE_JIT=0 ../../../bin/x64/Rterm.exe --vanilla --no-echo > /dev/null
make[2]: *** [Makefile.win:34: ../../../library/tools/R/tools.rdb] Error 139
make[1]: *** [Makefile.win:33: R] Error 1
make: *** [Makefile:18: all] Error 2

It looks to have compiled its own Rterm.exe, and segfaults when running it?
On 2020-08-21 18:48:42 murdoch.duncan at gmail.com wrote:
----
Sent using Guerrillamail.com
Block or report abuse: https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX
#
On 8/21/20 9:20 PM, m17hpj+bt626qpx8w70w--- via R-devel wrote:
You can try building with debug symbols, for simplicity even disabling 
optimization, and then running RTerm in a debugger and see where it is 
crashing. Maybe it is related to the problem you are seeing in the 
installed version of R.

Or, better from the other end, you could try to experiment with your 
system to find out which configuration may be impacting the problem. R 
is not doing anything special/custom linking to the system DLLs. You can 
check your PATH settings, make sure you run from cmd.exe (not Visual 
Studio, etc). You can start playing with the registry keys. Maybe there 
is some leftover from the Microsoft distribution of R (they have their 
own installer). Maybe there was some manual modification of registry 
keys by some external software, etc. You can read the sources to see 
which keys normally get set (src/gnuwin32/installer/*), or you can 
install into a fresh VM from the CRAN installer and check there.? 
Windows allow to set debugging flags on the dynamic loader (per binary - 
without recompilation), perhaps that might help too to identify why the 
wrong library is loaded (even though that tends to be verbose). It would 
be useful to know why it is happening, as you are not the first one who 
ran into a similar problem (the reporter of the bug did as well), but 
you are probably the only one who can find out.

Tomas