On 8/21/20 9:20 PM, m17hpj+bt626qpx8w70w--- via R-devel wrote:
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?
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
On 2020-08-21 18:48:42 murdoch.dun...@gmail.com wrote:
On 21/08/2020 12:53 p.m., m15g9g+1dq20lw4vyh1s--- via R-devel wrote:
Thanks for the response. Having spent a lot of the day trying to solve
this, as R is essential for my workflow, I've tried to debug via the binary
only as I haven't yet got the toolchain working - I'm quite inexperienced
at this.
I've confirmed the problem is exactly as described in the initial (albeit
old) bug report. The exception that's thrown within Visual Studio is:
"Exception thrown at 0x00007FFBF1E3C0C8 (ntdll.dll) in Rterm.exe:
0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF."
As the problem appears to be persistent and cross many versions of
Windows, could it hint towards this being a problem within R's codebase
rather than my specific setup?
I understand that this is hard to reproduce, however, and I'll doing my
best at trying to compile/debug from source if there are no obvious
answers.
On 2020-08-21 15:59:49 tomas.kalib...@gmail.com wrote:
On 8/21/20 2:34 PM, m1388m+moe1ydyn0hbs--- via R-devel wrote:
I am having exactly the same issue as the following bug report:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16515.
RTerm.exe hangs on startup, nothing is printed to the terminal. 32-bit
RTerm.exe runs fine.
No errors are displayed, but I see the same as the bug report in Event
Viewer.
I am running Windows 10 64-bit, v2010.
Thanks for the report, but please try to provide more information and
diagnose a bit of the problem on your own - this is a very rare problem,
many people use R on Windows 10, the 64-bit version. There must be
something special about your installation, your operating system, etc
and unless someone finds out what it is, the issue can't be fixed. You
will see that if you install a clean version of stock Windows 10 in a
virtual machine and install R 4.0.2 or R-devel from the CRAN installer,
it will work.
PR16515 was for a much older version of R, for a different version of
Windows, with detailed info of what was happening. Still, without any
clue why, and as nobody who could find out why could reproduce, it is
still open.
Thanks
Tomas
----
Sent using Guerrillamail.com
Block or report abuse:
https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
----
Sent using Guerrillamail.com
Block or report abuse:
https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
----
Sent using Guerrillamail.com
Block or report abuse:
https://www.guerrillamail.com//abuse/?a=UwxwABsFT5QHxR6m%2F3QacQCJQtiX
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
