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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ryan Novosielski
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 - [hidden email]
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ | Office of Advanced Research Computing - MSB C630, Newark
    `'


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

Duncan Murdoch-2
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 - [hidden email]
> || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
> ||  \\    of NJ | Office of Advanced Research Computing - MSB C630, Newark
>      `'
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

Ivan Krylov
In reply to this post by Ryan Novosielski
On Wed, 24 Jun 2020 18:56:06 +0000
Ryan Novosielski <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

attachment0 (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

Bjørn-Helge Mevik-3
In reply to this post by Ryan Novosielski
Ryan Novosielski <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

Ryan Novosielski
> On Jun 25, 2020, at 10:31 AM, Bjørn-Helge Mevik <[hidden email]> wrote:

>
> Signed PGP part
> Ryan Novosielski <[hidden email]> 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 - [hidden email]
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ | Office of Advanced Research Computing - MSB C630, Newark
     `'


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7

Ryan Novosielski
In reply to this post by Ivan Krylov
> On Jun 25, 2020, at 8:06 AM, Ivan Krylov <[hidden email]> wrote:

>
> On Wed, 24 Jun 2020 18:56:06 +0000
> Ryan Novosielski <[hidden email]> 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@amarel-test1 R-4.0.2-intel-19.1-build]$ ulimit -s
8192

Thanks for your help!

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


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

signature.asc (201 bytes) Download Attachment