R devel - Jun 2020 - R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

Hi there,

I initially asked about this on r-help and was told this might be a better
venue. I?m not really convinced from reading the posting guide, but I?ll give it
a shot. It was also suggested that the R-Project doesn?t really care about
building with ?non-standard? compilers, but I can?t find any evidence of that on
the website (indeed, there?s some mention of successful past builds, and the
build itself is successful).

I built R 4.0.2 with the Intel Parallel Studio XE compiler suite, versions
19.0.x to 19.1.1. Build seems to go fine. I built it like this:

module purge
module load intel/19.1.1
module list

export CC=icc
export CXX=icpc
export F77=ifort
export FC=ifort
export AR=xiar
export LD=xild

export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
export F77FLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
export FFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
export CXXFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5
-lpthread"

VERSION=4.0.1

/scratch/novosirj/install-files/R-${VERSION}/configure
--with-blas="$MKL" --with-lapack
--prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
       make -j32 && make check && make -j32 install

However, the ?make check" phase fails at this part:

Testing examples for package ?parallel?
make[2]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests/Examples'
make[1]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
make[1]: Entering directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
running strict specific tests
make[2]: Entering directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/eval-etc.R' ... OK
 comparing 'eval-etc.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/eval-etc.Rout.save' ...
OK
running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/simple-true.R' ... OK
 comparing 'simple-true.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/simple-true.Rout.save'
... OK
running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/arith-true.R' ... OK
 comparing 'arith-true.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/arith-true.Rout.save' ...
OK
running code in '/scratch/novosirj/install-files/R-4.0.1/tests/arith.R'
... OK
 comparing 'arith.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/arith.Rout.save' ... OK
running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/lm-tests.R' ... OK
 comparing 'lm-tests.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/lm-tests.Rout.save' ...
OK
/bin/sh: line 1: 62064 Segmentation fault      (core dumped) LANGUAGE=en
LC_ALL=C SRCDIR=/scratch/novosirj/install-files/R-4.0.1/tests
R_DEFAULT_PACKAGES= ../bin/R --vanilla <
/scratch/novosirj/install-files/R-4.0.1/tests/ok-errors.R >
ok-errors.Rout.fail 2>&1
running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/ok-errors.R' ...make[2]:
*** [ok-errors.Rout] Error 1
make[2]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
make[1]: *** [test-Specific] Error 2
make[1]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
make: *** [test-all-basics] Error 1

Is this something I should be concerned about, or something I can fix? Not
seeing any real information about what?s going wrong here. Here?s what?s
contained in ok-errors.Rout.fail:

---
R version 4.0.1 (2020-06-06) -- "See Things Now"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> #### STRICT test suite in the spirit of no-segfaults,
> #### but with explicit statements.
> 
> options(error=expression(NULL))
> stop("test of `options(error=expression(NULL))'")
Error: test of `options(error=expression(NULL))'
> 
> if(FALSE) {
+ ## these ought to work on machines with enough memory
+ ## These segfaulted in 1.3.x ,  give "could not allocate" errors now
+   integer(2^30+1)
+    double(2^30+1)
+   complex(2^30+1)
+ character(2^30+1)
+ vector("list", 2^30+2)
+ }
> 
> ## bad infinite recursion / on.exit / ... interactions
> ##   catch the error to permit different error messages emitted
> ##   (handling of infinite recursion is different in the AST interpreter
> ##   and the byte-code interpreter)
> 
> bar <- function() 1+1
> foo <- function() { on.exit(bar()); foo() }
> tryCatch(foo(), error=function(x) TRUE) # now simple "infinite
recursion"
*** caught segfault ***
address 0x7fff4dc1b9f8, cause 'memory not mapped'

Traceback:
1: foo()
2: foo()
3: foo()
4: foo()

...

2712: foo()
2713: foo()
2714: foo()
2715: foo()
2716: foo()
2717: foo()
2718: foo()
2719: doTryCatch(return(expr), name, parentenv, handler)
2720: tryCatchOne(expr, names, parentenv, handlers[[1L]])
2721: tryCatchList(expr, classes, parentenv, handlers)
2722: tryCatch(foo(), error = function(x) TRUE)
An irrecoverable exception occurred. R is aborting now ...
---

Thanks in advance.

--
____
|| \\UTGERS,  	 |---------------------------*O*---------------------------
||_// the State	 |         Ryan Novosielski - novosirj at rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
    `'


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20200624/d26e185b/attachment.sig>

If you just run the failed test, does it segfault?  What I get when I 
run it is

 > bar <- function() 1+1
 > foo <- function() { on.exit(bar()); foo() }
 > tryCatch(foo(), error=function(x) TRUE) # now simple "infinite
recursion"
[1] TRUE

Clearly a segfault on an infinite recursion is undesirable, but maybe 
not the end of the world: maybe it just makes your life harder when 
debugging.  Or maybe you'll get segfaults from non-buggy code too, which 
would be really bad.  But I think you're the only one who can debug 
this, and find out why R's error handling isn't working in your build.

Duncan Murdoch

On 24/06/2020 2:56 p.m., Ryan Novosielski wrote:
> Hi there,
> 
> I initially asked about this on r-help and was told this might be a better
venue. I?m not really convinced from reading the posting guide, but I?ll give it
a shot. It was also suggested that the R-Project doesn?t really care about
building with ?non-standard? compilers, but I can?t find any evidence of that on
the website (indeed, there?s some mention of successful past builds, and the
build itself is successful).
> 
> I built R 4.0.2 with the Intel Parallel Studio XE compiler suite, versions
19.0.x to 19.1.1. Build seems to go fine. I built it like this:
> 
> module purge
> module load intel/19.1.1
> module list
> 
> export CC=icc
> export CXX=icpc
> export F77=ifort
> export FC=ifort
> export AR=xiar
> export LD=xild
> 
> export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export F77FLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export FFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export CXXFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5
-lpthread"
> 
> VERSION=4.0.1
> 
> /scratch/novosirj/install-files/R-${VERSION}/configure
--with-blas="$MKL" --with-lapack
--prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
>         make -j32 && make check && make -j32 install
> 
> However, the ?make check" phase fails at this part:
> 
> Testing examples for package ?parallel?
> make[2]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests/Examples'
> make[1]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
> make[1]: Entering directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
> running strict specific tests
> make[2]: Entering directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
> running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/eval-etc.R' ... OK
>   comparing 'eval-etc.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/eval-etc.Rout.save' ...
OK
> running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/simple-true.R' ... OK
>   comparing 'simple-true.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/simple-true.Rout.save'
... OK
> running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/arith-true.R' ... OK
>   comparing 'arith-true.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/arith-true.Rout.save' ...
OK
> running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/arith.R' ... OK
>   comparing 'arith.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/arith.Rout.save' ... OK
> running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/lm-tests.R' ... OK
>   comparing 'lm-tests.Rout' to
'/scratch/novosirj/install-files/R-4.0.1/tests/lm-tests.Rout.save' ...
OK
> /bin/sh: line 1: 62064 Segmentation fault      (core dumped) LANGUAGE=en
LC_ALL=C SRCDIR=/scratch/novosirj/install-files/R-4.0.1/tests
R_DEFAULT_PACKAGES= ../bin/R --vanilla <
/scratch/novosirj/install-files/R-4.0.1/tests/ok-errors.R >
ok-errors.Rout.fail 2>&1
> running code in
'/scratch/novosirj/install-files/R-4.0.1/tests/ok-errors.R' ...make[2]:
*** [ok-errors.Rout] Error 1
> make[2]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
> make[1]: *** [test-Specific] Error 2
> make[1]: Leaving directory
`/mnt/scratch/novosirj/R-4.0.1-intel-19.1-build/tests'
> make: *** [test-all-basics] Error 1
> 
> Is this something I should be concerned about, or something I can fix? Not
seeing any real information about what?s going wrong here. Here?s what?s
contained in ok-errors.Rout.fail:
> 
> ---
> R version 4.0.1 (2020-06-06) -- "See Things Now"
> Copyright (C) 2020 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
> 
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
> 
>> #### STRICT test suite in the spirit of no-segfaults,
>> #### but with explicit statements.
>>
>> options(error=expression(NULL))
>> stop("test of `options(error=expression(NULL))'")
> Error: test of `options(error=expression(NULL))'
>>
>> if(FALSE) {
> + ## these ought to work on machines with enough memory
> + ## These segfaulted in 1.3.x ,  give "could not allocate"
errors now
> +   integer(2^30+1)
> +    double(2^30+1)
> +   complex(2^30+1)
> + character(2^30+1)
> + vector("list", 2^30+2)
> + }
>>
>> ## bad infinite recursion / on.exit / ... interactions
>> ##   catch the error to permit different error messages emitted
>> ##   (handling of infinite recursion is different in the AST
interpreter
>> ##   and the byte-code interpreter)
>>
>> bar <- function() 1+1
>> foo <- function() { on.exit(bar()); foo() }
>> tryCatch(foo(), error=function(x) TRUE) # now simple "infinite
recursion"
> 
> *** caught segfault ***
> address 0x7fff4dc1b9f8, cause 'memory not mapped'
> 
> Traceback:
> 1: foo()
> 2: foo()
> 3: foo()
> 4: foo()
> 
> ...
> 
> 2712: foo()
> 2713: foo()
> 2714: foo()
> 2715: foo()
> 2716: foo()
> 2717: foo()
> 2718: foo()
> 2719: doTryCatch(return(expr), name, parentenv, handler)
> 2720: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 2721: tryCatchList(expr, classes, parentenv, handlers)
> 2722: tryCatch(foo(), error = function(x) TRUE)
> An irrecoverable exception occurred. R is aborting now ...
> ---
> 
> Thanks in advance.
> 
> --
> ____
> || \\UTGERS,  	 |---------------------------*O*---------------------------
> ||_// the State	 |         Ryan Novosielski - novosirj at rutgers.edu
> || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
> ||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
>      `'
> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

On Wed, 24 Jun 2020 18:56:06 +0000
Ryan Novosielski <novosirj at rutgers.edu> wrote:

On my machine, getOption('expressions') is 5000 and the example from
the test correctly stops with length(traceback()) == 2500. (And the
simpler example of f <- function() f(); f() stops with
length(traceback()) == 5000).
> Traceback:
<...>
> 2718: foo()
This (traceback() being more than 2500 entries long) seems to imply
that the stack size check is somehow skipped. (Perhaps optimized away?)
The evaluation depth limit is checked in src/main/eval.c, line 705 [*],
followed by stack size check. Can you attach the debugger and take a
look at the values of R_EvalDepth and R_Expressions while executing the
text? What about R_CStackStart and R_CStackLimit? What is the stack
size limit (ulimit -s?) on the machine running this test?

-- 
Best regards,
Ivan

[*]
https://github.com/wch/r-source/blob/8d7ac4699fba640d030703fa010b66bf26054cbd/src/main/eval.c#L705

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: ???????????????? ?????????????? OpenPGP
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20200625/2fe9360d/attachment.sig>

Ryan Novosielski <novosirj at rutgers.edu> writes:
> Hi there,
>
> I initially asked about this on r-help and was told this might be a better
venue. I?m not really convinced from reading the posting guide, but I?ll give it
a shot. It was also suggested that the R-Project doesn?t really care about
building with ?non-standard? compilers, but I can?t find any evidence of that on
the website (indeed, there?s some mention of successful past builds, and the
build itself is successful).
>
> I built R 4.0.2 with the Intel Parallel Studio XE compiler suite, versions
19.0.x to 19.1.1. Build seems to go fine. I built it like this:
>
> module purge
> module load intel/19.1.1
> module list
>
> export CC=icc
> export CXX=icpc
> export F77=ifort
> export FC=ifort
> export AR=xiar
> export LD=xild
>
> export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export F77FLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export FFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export CXXFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
> export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5
-lpthread"
>
> VERSION=4.0.1
>
> /scratch/novosirj/install-files/R-${VERSION}/configure
--with-blas="$MKL" --with-lapack
--prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
>        make -j32 && make check && make -j32 install
For what it is worth, we used to build R with the Intel compilers and
MKL on our HPC cluster (on CentOS Linux), and we used the following
setup.  Note the comments about -fp-model precise and -ipo.  It might no
longer be a problem, but maybe worth checking.

fast="-ip -O3 -qopt-mem-layout-trans=3 -xHost -mavx"
## Notes:
## -static and -ipo break compilation
## -no-prec-div breaks make check
## -fp-model precise is needed for make check
## -wd188 removes a lot of warnings (see R Inst. & Adm. manual)
export CC="icc"
export CFLAGS="$fast -wd188 -fp-model precise"
export F77="ifort"
export FFLAGS="$fast -fp-model precise"
export CXX="icpc"
export CXXFLAGS="$fast -fp-model precise"
export FC="ifort"
export FCFLAGS="$fast -fp-model precise"

## This works with intel 2011.10, at least:
BLAS=--with-blas='-mkl=parallel'
LAPACK=--with-lapack

## To make the linker find libraries in modules:
export LDFLAGS=$(echo $LD_LIBRARY_PATH | sed 's/^/-L/; s/:/ -L/g')

./configure "$BLAS" "$LAPACK" --enable-BLAS-shlib
--enable-R-shlib
make -j 8
make check
make install

-- 
Regards,
Bj?rn-Helge Mevik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20200625/b365e557/attachment.sig>

> On Jun 25, 2020, at 10:31 AM, Bj?rn-Helge Mevik <b.h.mevik at
usit.uio.no> wrote:
> 
> Signed PGP part
> Ryan Novosielski <novosirj at rutgers.edu> writes:
> 
>> Hi there,
>> 
>> I initially asked about this on r-help and was told this might be a
better venue. I?m not really convinced from reading the posting guide, but I?ll
give it a shot. It was also suggested that the R-Project doesn?t really care
about building with ?non-standard? compilers, but I can?t find any evidence of
that on the website (indeed, there?s some mention of successful past builds, and
the build itself is successful).
>> 
>> I built R 4.0.2 with the Intel Parallel Studio XE compiler suite,
versions 19.0.x to 19.1.1. Build seems to go fine. I built it like this:
>> 
>> module purge
>> module load intel/19.1.1
>> module list
>> 
>> export CC=icc
>> export CXX=icpc
>> export F77=ifort
>> export FC=ifort
>> export AR=xiar
>> export LD=xild
>> 
>> export CFLAGS="-O3 -ipo -qopenmp
-axAVX,CORE-AVX2,CORE-AVX512"
>> export F77FLAGS="-O3 -ipo -qopenmp
-axAVX,CORE-AVX2,CORE-AVX512"
>> export FFLAGS="-O3 -ipo -qopenmp
-axAVX,CORE-AVX2,CORE-AVX512"
>> export CXXFLAGS="-O3 -ipo -qopenmp
-axAVX,CORE-AVX2,CORE-AVX512"
>> export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5
-lpthread"
>> 
>> VERSION=4.0.1
>> 
>> /scratch/novosirj/install-files/R-${VERSION}/configure
--with-blas="$MKL" --with-lapack
--prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
>>       make -j32 && make check && make -j32 install
> 
> For what it is worth, we used to build R with the Intel compilers and
> MKL on our HPC cluster (on CentOS Linux), and we used the following
> setup.  Note the comments about -fp-model precise and -ipo.  It might no
> longer be a problem, but maybe worth checking.
> 
> fast="-ip -O3 -qopt-mem-layout-trans=3 -xHost -mavx"
> ## Notes:
> ## -static and -ipo break compilation
> ## -no-prec-div breaks make check
> ## -fp-model precise is needed for make check
> ## -wd188 removes a lot of warnings (see R Inst. & Adm. manual)
> export CC="icc"
> export CFLAGS="$fast -wd188 -fp-model precise"
> export F77="ifort"
> export FFLAGS="$fast -fp-model precise"
> export CXX="icpc"
> export CXXFLAGS="$fast -fp-model precise"
> export FC="ifort"
> export FCFLAGS="$fast -fp-model precise"
> 
> ## This works with intel 2011.10, at least:
> BLAS=--with-blas='-mkl=parallel'
> LAPACK=--with-lapack
> 
> ## To make the linker find libraries in modules:
> export LDFLAGS=$(echo $LD_LIBRARY_PATH | sed 's/^/-L/; s/:/ -L/g')
> 
> ./configure "$BLAS" "$LAPACK" --enable-BLAS-shlib
--enable-R-shlib
> make -j 8
> make check
> make install
Thanks, Bj?rn; -ipo no longer breaks compilation (I didn?t specify it, but I see
that it was getting added automatically). I was really hoping that
"-fp-model precise? (which also implies -prec-div which would seem to
affect the other option mentioned) would have an impact on ?make check? here,
but apparently not. Also -wd188 is no longer required to hide warnings; this
doesn?t seem to be happening anymore (but remember it myself from earlier on).

I guess it might make sense to check with Intel; we have support. I wish I could
remember if this ever worked right, but I don?t think I thought/knew to run
"make check" on our older builds.

--
____
|| \\UTGERS,  	 |---------------------------*O*---------------------------
||_// the State	 |         Ryan Novosielski - novosirj at rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20200626/f519fae7/attachment.sig>

> On Jun 25, 2020, at 8:06 AM, Ivan Krylov <krylov.r00t at gmail.com>
wrote:
> 
> On Wed, 24 Jun 2020 18:56:06 +0000
> Ryan Novosielski <novosirj at rutgers.edu> wrote:
> 
> On my machine, getOption('expressions') is 5000 and the example
from
> the test correctly stops with length(traceback()) == 2500. (And the
> simpler example of f <- function() f(); f() stops with
> length(traceback()) == 5000).
> 
>> Traceback:
> 
> <...>
> 
>> 2718: foo()
> 
> This (traceback() being more than 2500 entries long) seems to imply
> that the stack size check is somehow skipped. (Perhaps optimized away?)
> The evaluation depth limit is checked in src/main/eval.c, line 705 [*],
> followed by stack size check. Can you attach the debugger and take a
> look at the values of R_EvalDepth and R_Expressions while executing the
> text? What about R_CStackStart and R_CStackLimit? What is the stack
> size limit (ulimit -s?) on the machine running this test?
I can do that. I figure you may have more experience debugging R than I have,
but I know the R command is a script, and that running the R binary directly
doesn?t result in a working run. So what I?ve tried is to do ?gdb /bin/bash? and
then running R from that shell. Is that best/are there guidelines? I?m not much
of an expert in this area. Is there also any special way I need to compile R to
have the appropriate symbols?

The shell I?m running in had 8192 for stack size:

[novosirj at amarel-test1 R-4.0.2-intel-19.1-build]$ ulimit -s
8192

Thanks for your help!

--
____
|| \\UTGERS,  	 |---------------------------*O*---------------------------
||_// the State	 |         Ryan Novosielski - novosirj at rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20200626/37b4c9c9/attachment.sig>