Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, errors in "make check" on CentOS 7.7-7.9
> On Apr 16, 2021, at 2:32 PM, Ivan Krylov wrote:
>
> On Fri, 16 Apr 2021 18:06:51 +
> Ryan Novosielski wrote:
>
>> Well it definitely somehow could have, since it did
>
> Wow! This is strange, but at least it should be easy to fix. Try editing
> the config.site file in the root of the R source directory and setting
> R_C_STACK_DIRECTION=down there. (Make sure to uncomment the line!)
> Re-run .../configure, make sure that src/include/config.h contains
> #define C_STACK_DIRECTION 1 and build R again.
>
> Does the crash go away?
So, it does, and no other crashes, though the checks fail in a couple of
places, and the final status is error: in tests/reg-tests-1d.R, and also
reg-packages.R (those are the only two that have .Rout.fail files).
make[3]: Entering directory
`/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests'
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/array-subset.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1a.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1b.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1c.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1d.R'
...make[3]: *** [reg-tests-1d.Rout] Error 1
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-2.R'
... OK
comparing 'reg-tests-2.Rout' to
'/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-2.Rout.save' ... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-examples1.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-examples2.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-packages.R'
...make[3]: *** [reg-packages.Rout] Error 1
running code in
'/scratch/novosirj/install-files/R-4.0.5/tests/p-qbeta-strict-tst.R' ... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/r-strict-tst.R'
... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO.R' ... OK
comparing 'reg-IO.Rout' to
'/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO.Rout.save' ... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO2.R' ... OK
comparing 'reg-IO2.Rout' to
'/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO2.Rout.save' ... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-plot.R' ...
OK
comparing 'reg-plot.pdf' to
'/scratch/novosirj/install-files/R-4.0.5/tests/reg-plot.pdf.save' ... OK
running code in
'/scratch/novosirj/install-files/R-4.0.5/tests/reg-S4-examples.R' ... OK
running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-BLAS.R' ...
OK
make[3]: Leaving directory
`/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests'
make[2]: *** [test-Reg] Error 2
make[2]: Leaving directory
`/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests'
make[1]: *** [test-all-basics] Error 1
make[1]: Target `check' not remade because of errors.
make[1]: Leaving directory
`/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests'
make: *** [check] Error 2
I’m a little new to reading these results, so I’m not sure exactly what I’m
looking for. I’ve shared them in the event that what I put in this e-mail is
useless:
reg-tests-1d.Rout.fail:
https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EYK2JHWQ1-9Dvu6gK9lrkRIBkEyA4QqkeH7C4gmbAYyBBQ?e=lfGJL7
reg-packages.Rout.fail:
https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EazCjI6fRnNKhQASFPeySBUBENVpCqCljFg3-sokBZJnAw?e=8lwywe
Anyhow, there appear to be a number of places, if I have this right:
[novosirj@amarel-test2 tests]$ grep -i -B2 ^error reg-packages.Rout.fail
building package exSexpr ...
Converting Rd files to LaTeX
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
pdflatex is not available
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
pdflatex is not available
Error in running tools::texi2pdf()
--
Hmm ... looks like a package
Creating pdf output from LaTeX ...
Error: R CMD build failed (no tarball) for package exSexpr
These maybe seem like they’re OK, and if I don’t have pdf2latex, they’re
expected? Unless I should be looking for something else other than “^Error”.
That seemed like the only place something could be going wrong.
For the regression tests, these seem like some of them are actual problems, but
maybe someone here knows if some are expected?
[novosirj@amarel-test2 R-4.0.5-intel-19.1-build]$ grep -i -B2 "Asserted error"
tests/reg-tests-1d.Rout.fail
> op <- options(device=function(...){}) # non-sense device
> tools::assertError(plot.new(), verbose = TRUE)
Asserted error: no active device and default getOption("device") is invalid
> if(no.grid <- !("grid" %in% loadedNamespaces())) requireNamespace("grid")
> tools::assertError(grid::grid.newpage(), verbose =
Re: [Rd] R Console Bug?
Sorry, unable to reproduce on macOS, in R console:
> dyn.load("test.so")
> .Call("printtest",1e4L)
Processing data chunk 1 of 3
[==] 100%
Processing data chunk 2 of 3
[==] 100%
Processing data chunk 3 of 3
[==] 100%
NULL
But honestly I'm not sure sure I understand the report. R_FlushConsole is a
no-op for terminal console and your code just prints on stderr anyway (which is
not buffered). All this does is just a lot of \r output (which is highly
inefficient anywhere but in Terminal by definition). Can you clarify what the
code tries to trigger?
Cheers,
Simon
> On Apr 16, 2021, at 23:11, Morgan Morgan wrote:
>
> Hi,
>
> I am getting a really weird behaviour with the R console.
> Here is the code to reproduce it.
>
> 1/ C code: ---
>
> SEXP printtest(SEXP x) {
> const int PBWIDTH = 30, loop = INTEGER(x)[0];
> int val, lpad;
> double perc;
> char PBSTR[PBWIDTH], PBOUT[PBWIDTH];
> memset(PBSTR,'=', sizeof(PBSTR));
> memset(PBOUT,'-', sizeof(PBOUT));
> for (int k = 0; k < 3; ++k) {
>REprintf("\n Processing data chunk %d of 3\n",k+1);
>for (int i = 0; i < loop; ++i) {
> perc = (double) i/(loop-1);
> val = (int) (perc * 100);
> lpad = (int) (perc * PBWIDTH);
> REprintf("\r [%.*s%.*s] %3d%%", lpad, PBSTR, PBWIDTH - lpad, PBOUT,
> val);
> R_FlushConsole();
>}
>REprintf("\n");
> }
> return R_NilValue;
> }
>
> 2/ Build so/dll: ---
>
> R CMD SHLIB
>
> 3/ Run code : ---
>
> dyn.load("test.so")
> .Call("printtest",1e4L)
> dyn.unload("test.so")
>
> 4/ Issue: ---
> If you run the above code in RStudio, it works well both on Mac and Windows.
> If you run it in Windows cmd, it is slow.
> If you run it in Windows RGui, it is slow but also all texts are flushed.
> If you run it in Mac terminal, it runs perfectly.
> If you run it in Mac R Console, it prints something like :
>> .Call("printtest",1e4L)
> [==] 100%NULL] 0%
>
> I am using R 4.0.4 (Mac) / 4.0.5 (Windows)
>
> Is that a bug or am I doing something wrong?
>
> Thank you
> Best regards,
> Morgan
>
> [[alternative HTML version deleted]]
>
> __
> 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
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
> On Apr 16, 2021, at 2:32 PM, Ivan Krylov wrote:
>
> On Fri, 16 Apr 2021 18:06:51 +
> Ryan Novosielski wrote:
>
>> Well it definitely somehow could have, since it did
>
> Wow! This is strange, but at least it should be easy to fix. Try editing
> the config.site file in the root of the R source directory and setting
> R_C_STACK_DIRECTION=down there. (Make sure to uncomment the line!)
> Re-run .../configure, make sure that src/include/config.h contains
> #define C_STACK_DIRECTION 1 and build R again.
>
> Does the crash go away?
Will give it a shot, thanks, that’s great!
> If it does, are you interested in finding out
> what went wrong in the configure test for stack direction?
I’m interested in putting in the time to make this build/the tests succeed for
anyone else who wants to use R with the Intel Parallel Studio/oneAPI for sure.
I’m not actually sure whether it makes much difference, vs. gcc, beyond using
the MKL for BLAS/LAPACK, but we do pay for this compiler, and try to use it
anytime we might get a slight boost out of it. One of the reasons too is that
it can do auto-vectorization and build fat binaries for the various processor
instruction sets. I don’t know how much that matters in R either, but if we can
get the best performance out of our system-wide install from that, we want to
do it.
> There are lines in m4/R.m4 that I'm not sure I understand:
>
>if test ${?} = 1; then
> r_cv_cstack_direction=down
>elif test ${?} = 1; then
> r_cv_cstack_direction=up
>fi
>
> How can elif branch have the same condition as the if branch? Shouldn't
> the second test had been for $? = 255? On the other hand, if the elif
> branch was never taken, how did R_CStackDir become -1?
IANAm4P, but that does seem like a pretty good question. I guess there’s
probably some mode of m4 I could run against that and see if there’s any
indication?
--
#BlackLivesMatter
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
On Fri, 16 Apr 2021 18:06:51 +
Ryan Novosielski wrote:
> Well it definitely somehow could have, since it did
Wow! This is strange, but at least it should be easy to fix. Try editing
the config.site file in the root of the R source directory and setting
R_C_STACK_DIRECTION=down there. (Make sure to uncomment the line!)
Re-run .../configure, make sure that src/include/config.h contains
#define C_STACK_DIRECTION 1 and build R again.
Does the crash go away? If it does, are you interested in finding out
what went wrong in the configure test for stack direction?
There are lines in m4/R.m4 that I'm not sure I understand:
if test ${?} = 1; then
r_cv_cstack_direction=down
elif test ${?} = 1; then
r_cv_cstack_direction=up
fi
How can elif branch have the same condition as the if branch? Shouldn't
the second test had been for $? = 255? On the other hand, if the elif
branch was never taken, how did R_CStackDir become -1?
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
> On Apr 16, 2021, at 12:12 PM, Ivan Krylov wrote:
>
> On Thu, 15 Apr 2021 22:46:56 +
> Ryan Novosielski wrote:
>
>> (gdb) print $_siginfo._sifields._sigfault
>> $1 = {
>> si_addr = 0x7f7fecf8, _addr_lsb = 0,
>> _addr_bnd = {_lower = 0x9215f829ff58, _upper = 0x7f7fecf8}
>> }
>
>> (gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
>> $5 = 18446744073701307232
>
> Okay, this is clearly a stack overflow: the faulting address is close
> to addresses of other stack variables, and the stack usage, calculated
> manually as 140737488207872 - 0x7f7ff360, is 8244392, which is
> above the (7969177), but the value that gdb gives you looks really
> strange. I could only get that value when I calculated
> -1 * (140737488207872 - 0x7f7ff360) and reinterpreted it as
> unsigned.
>
> What is the value of R_CStackDir at the moment of crash? Could it have
> somehow became -1 despite the stack growing down?
Well it definitely somehow could have, since it did:
Program received signal SIGSEGV, Segmentation fault.
bcEval.R (body=0x3eb7748, rho=0x3f72770, useCache=TRUE) at
/scratch/novosirj/install-files/R-4.0.5/src/main/eval.c:6478
6478 codebase = pc = BCCODE(body);
(gdb) print R_CStackDir
$1 = -1
--
#BlackLivesMatter
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
On Thu, 15 Apr 2021 22:46:56 +
Ryan Novosielski wrote:
> (gdb) print $_siginfo._sifields._sigfault
> $1 = {
> si_addr = 0x7f7fecf8, _addr_lsb = 0,
> _addr_bnd = {_lower = 0x9215f829ff58, _upper = 0x7f7fecf8}
> }
> (gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
> $5 = 18446744073701307232
Okay, this is clearly a stack overflow: the faulting address is close
to addresses of other stack variables, and the stack usage, calculated
manually as 140737488207872 - 0x7f7ff360, is 8244392, which is
above the (7969177), but the value that gdb gives you looks really
strange. I could only get that value when I calculated
-1 * (140737488207872 - 0x7f7ff360) and reinterpreted it as
unsigned.
What is the value of R_CStackDir at the moment of crash? Could it have
somehow became -1 despite the stack growing down?
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem adding gdb to RTOOLS40 on Windows
On Thu, Apr 15, 2021 at 10:19 AM Bravington, Mark (Data61, Hobart) wrote: > > Excellent, thank you all. Doing "pacman -Syu" before "pacman -S gdb" did > the trick, and yes it's a different version of gdb compared to what pacman > was previously trying to install. Might be worth updating the RTOOLS40 > documentation to recommend doing -Syu first. OK I have added a line to the docs. FYI, you can combine the two commands into one: pacman -Sy mingw-w64-x86_64-gdb This will first update the repository index (-y) and the install the package. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Console Bug?
Hi,
I am getting a really weird behaviour with the R console.
Here is the code to reproduce it.
1/ C code: ---
SEXP printtest(SEXP x) {
const int PBWIDTH = 30, loop = INTEGER(x)[0];
int val, lpad;
double perc;
char PBSTR[PBWIDTH], PBOUT[PBWIDTH];
memset(PBSTR,'=', sizeof(PBSTR));
memset(PBOUT,'-', sizeof(PBOUT));
for (int k = 0; k < 3; ++k) {
REprintf("\n Processing data chunk %d of 3\n",k+1);
for (int i = 0; i < loop; ++i) {
perc = (double) i/(loop-1);
val = (int) (perc * 100);
lpad = (int) (perc * PBWIDTH);
REprintf("\r [%.*s%.*s] %3d%%", lpad, PBSTR, PBWIDTH - lpad, PBOUT,
val);
R_FlushConsole();
}
REprintf("\n");
}
return R_NilValue;
}
2/ Build so/dll: ---
R CMD SHLIB
3/ Run code : ---
dyn.load("test.so")
.Call("printtest",1e4L)
dyn.unload("test.so")
4/ Issue: ---
If you run the above code in RStudio, it works well both on Mac and Windows.
If you run it in Windows cmd, it is slow.
If you run it in Windows RGui, it is slow but also all texts are flushed.
If you run it in Mac terminal, it runs perfectly.
If you run it in Mac R Console, it prints something like :
> .Call("printtest",1e4L)
[==] 100%NULL] 0%
I am using R 4.0.4 (Mac) / 4.0.5 (Windows)
Is that a bug or am I doing something wrong?
Thank you
Best regards,
Morgan
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.0 scheduled for May 18
Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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
