date:20210415

Re: [Rd] problem adding gdb to RTOOLS40 on Windows

2021-04-15 Thread Tomas Kalibera


On 4/15/21 6:52 AM, Bravington, Mark (Data61, Hobart) wrote:

I've not been able to install gdb for RTOOLS40 on Windows 10. The rtools 
installer (rtools40-x64_86.exe) doesn't seem to include gdb by default, and 
when I follow the instructions for adding gdb (which I tracked down at 
https://github.com/r-windows/docs/blob/master/faq.md) this is what happened:



$ pacman -S mingw-w64-x86_64-gdb
resolving dependencies...
looking for conflicting packages...

Packages (8) mingw-w64-x86_64-expat-2.2.9-9002
  mingw-w64-x86_64-gettext-0.19.8.1-9002
  mingw-w64-x86_64-libsystre-1.0.1-9002
  mingw-w64-x86_64-libtre-git-r128.6fb7206-9002
  mingw-w64-x86_64-ncurses-6.1.20180526-9002
  mingw-w64-x86_64-readline-8.0.001-2
  mingw-w64-x86_64-termcap-1.3.1-9002
  mingw-w64-x86_64-gdb-8.3.1-9500

Total Download Size:3.46 MiB
Total Installed Size:  83.77 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
error: failed retrieving file 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' 
from cloud.r-project.org : The requested URL returned error: 404
error: failed retrieving file 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' 
from cran.r-project.org : The requested URL returned error: 404
error: failed retrieving file 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' 
from dl.bintray.com : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Something very similar happens if I try the 32bit version.

Do you have any suggestions?

  - I used to have this stuff working OK with R3.6/RTOOLS35 but have not needed 
to go back to C for a while. The version of gdb in RTOOLS is 7.9.1; I tried 
copying that gdb.exe into RTOOLS40 but it just exited instantly when I tried to 
run it from there.


If you can still run gdb in your Rtools 3.5 installation, you should be 
able to use it to connect to the R session to debug, even if that R 
session is run say from a terminal that originates from Rtools 4.


In the R session run Sys.getpid().
In the gdb session, run

solib-search-path
attach xxx
(where xxx is the PID number)


  - NB I have absolutely no idea what is meant by msys2 or pacman or any of 
that, I'm just following instructions...


Msys2 is software distribution originating from archlinux, with pacman 
package manager. Rtools4 is a customized version of Msys2. You should be 
able to use gdb from any distribution, including Rtools 3.5 or say 
vanilla Msys2 (that is what I do when building for UCRT - I use gdb and 
other tools from vanilla Msys2).


Tomas




Thanks
Mark

  



Mark Bravington
CSIRO Marine Lab
Hobart
Australia

__
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] problem adding gdb to RTOOLS40 on Windows

2021-04-15 Thread Avraham Adler

Also, packages should be installed in the MSYS2 environment and not the
MINGW64. Invoke msys2.exe, synchronize with Jeroen’s via the pacman -Syu,
and then try the install. It should work as Jeroen has gdb in the upstream
repository [
https://github.com/r-windows/rtools-packages/tree/master/mingw-w64-gdb]

Thanks,

Avi

On Thu, Apr 15, 2021 at 2:59 AM Voeten, C.C. 
wrote:

> Hi Mark,
>
> Try pacman -Suy first to update pacman's package database. It's quite
> possible that the versions pacman is trying to install are no longer
> available due to being out of date.
>
> HTH,
> Cesko
>
> -Original Message-
> From: R-devel  On Behalf Of Bravington,
> Mark (Data61, Hobart)
> Sent: Thursday, April 15, 2021 6:53 AM
> To: R-Devel-2 
> Subject: [Rd] problem adding gdb to RTOOLS40 on Windows
>
> I've not been able to install gdb for RTOOLS40 on Windows 10. The rtools
> installer (rtools40-x64_86.exe) doesn't seem to include gdb by default, and
> when I follow the instructions for adding gdb (which I tracked down at
> https://github.com/r-windows/docs/blob/master/faq.md) this is what
> happened:
>
> 
> 
> $ pacman -S mingw-w64-x86_64-gdb
> resolving dependencies...
> looking for conflicting packages...
>
> Packages (8) mingw-w64-x86_64-expat-2.2.9-9002
>  mingw-w64-x86_64-gettext-0.19.8.1-9002
>  mingw-w64-x86_64-libsystre-1.0.1-9002
>  mingw-w64-x86_64-libtre-git-r128.6fb7206-9002
>  mingw-w64-x86_64-ncurses-6.1.20180526-9002
>  mingw-w64-x86_64-readline-8.0.001-2
>  mingw-w64-x86_64-termcap-1.3.1-9002
>  mingw-w64-x86_64-gdb-8.3.1-9500
>
> Total Download Size:3.46 MiB
> Total Installed Size:  83.77 MiB
>
> :: Proceed with installation? [Y/n] y
> :: Retrieving packages...
> error: failed retrieving file
> 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' from cloud.r-project.org
> : The requested URL returned error: 404
> error: failed retrieving file
> 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' from cran.r-project.org
> : The requested URL returned error: 404
> error: failed retrieving file
> 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' from dl.bintray.com :
> The requested URL returned error: 404
> warning: failed to retrieve some files
> error: failed to commit transaction (failed to retrieve some files)
> Errors occurred, no packages were upgraded.
>
> Something very similar happens if I try the 32bit version.
>
> Do you have any suggestions?
>
>  - I used to have this stuff working OK with R3.6/RTOOLS35 but have not
> needed to go back to C for a while. The version of gdb in RTOOLS is 7.9.1;
> I tried copying that gdb.exe into RTOOLS40 but it just exited instantly
> when I tried to run it from there.
>
>  - NB I have absolutely no idea what is meant by msys2 or pacman or any of
> that, I'm just following instructions...
>
>
> Thanks
> Mark
>
>
>
>
> Mark Bravington
> CSIRO Marine Lab
> Hobart
> Australia
>
> __
> 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 from Gmail Mobile

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem adding gdb to RTOOLS40 on Windows

2021-04-15 Thread Bravington, Mark (Data61, Hobart)

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.

Jeroen's documentation says to do the pacman bit from mingw64, and separately 
from mingw32--- whereas Avraham's suggestion is to do it just from msys2.  I 
actually did both; gdb seems to end up in the same place regardless, but 
tomorrow I'll find out if it's *really* worked...

Thanks
Mark

Mark Bravington
CSIRO Marine Lab
Hobart
Australia



From: Avraham Adler 
Sent: Thursday, 15 April 2021 17:09
To: Voeten, C.C.
Cc: Bravington, Mark (Data61, Hobart); R-Devel-2
Subject: Re: [Rd] problem adding gdb to RTOOLS40 on Windows

Also, packages should be installed in the MSYS2 environment and not the 
MINGW64. Invoke msys2.exe, synchronize with Jeroen’s via the pacman -Syu, and 
then try the install. It should work as Jeroen has gdb in the upstream 
repository [
https://github.com/r-windows/rtools-packages/tree/master/mingw-w64-gdb]

Thanks,

Avi

On Thu, Apr 15, 2021 at 2:59 AM Voeten, C.C. 
mailto:c.c.voe...@hum.leidenuniv.nl>> wrote:
Hi Mark,

Try pacman -Suy first to update pacman's package database. It's quite possible 
that the versions pacman is trying to install are no longer available due to 
being out of date.

HTH,
Cesko

-Original Message-
From: R-devel 
mailto:r-devel-boun...@r-project.org>> On Behalf 
Of Bravington, Mark (Data61, Hobart)
Sent: Thursday, April 15, 2021 6:53 AM
To: R-Devel-2 mailto:r-devel@r-project.org>>
Subject: [Rd] problem adding gdb to RTOOLS40 on Windows

I've not been able to install gdb for RTOOLS40 on Windows 10. The rtools 
installer (rtools40-x64_86.exe) doesn't seem to include gdb by default, and 
when I follow the instructions for adding gdb (which I tracked down at 
https://github.com/r-windows/docs/blob/master/faq.md) this is what happened:



$ pacman -S mingw-w64-x86_64-gdb
resolving dependencies...
looking for conflicting packages...

Packages (8) mingw-w64-x86_64-expat-2.2.9-9002
 mingw-w64-x86_64-gettext-0.19.8.1-9002
 mingw-w64-x86_64-libsystre-1.0.1-9002
 mingw-w64-x86_64-libtre-git-r128.6fb7206-9002
 mingw-w64-x86_64-ncurses-6.1.20180526-9002
 mingw-w64-x86_64-readline-8.0.001-2
 mingw-w64-x86_64-termcap-1.3.1-9002
 mingw-w64-x86_64-gdb-8.3.1-9500

Total Download Size:3.46 MiB
Total Installed Size:  83.77 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
error: failed retrieving file 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' 
from cloud.r-project.org : The requested URL 
returned error: 404
error: failed retrieving file 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' 
from cran.r-project.org : The requested URL returned 
error: 404
error: failed retrieving file 'mingw-w64-x86_64-gdb-8.3.1-9500-any.pkg.tar.xz' 
from dl.bintray.com : The requested URL returned error: 
404
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

Something very similar happens if I try the 32bit version.

Do you have any suggestions?

 - I used to have this stuff working OK with R3.6/RTOOLS35 but have not needed 
to go back to C for a while. The version of gdb in RTOOLS is 7.9.1; I tried 
copying that gdb.exe into RTOOLS40 but it just exited instantly when I tried to 
run it from there.

 - NB I have absolutely no idea what is meant by msys2 or pacman or any of 
that, I'm just following instructions...


Thanks
Mark




Mark Bravington
CSIRO Marine Lab
Hobart
Australia

__
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 from Gmail Mobile

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] nchar(x, type = "bytes") seems slower than it could be

2021-04-15 Thread Tomas Kalibera


For reference, fixed in R-devel (80153).
Tomas

On 3/30/21 10:20 AM, Tomas Kalibera wrote:
Thanks for the report, you are probably running into the overhead of 
the eager creation of the error message. On my system, with your 
micro-benchmark, it is about 10x. I've tested simply by uncommenting 
it and re-running the benchmark. I'll fix (this is not a good task for 
a contributed patch).


Best,
Tomas

On 3/30/21 8:02 AM, Hugh Parsonage wrote:

While profiling some C code, I rolled my own nchar function which
appears to be much faster than base R's (25 times faster for a 10M
length vector).  Obviously base::nchar provides significantly more
features than my barebones function (C snippet below); however, for
argument type = "bytes" it seems that the R_nchar and do_nchar
functions do not actually do anything more than this function.
My suspicion is that I have overlooked some subtlety in the base R
code, or that my benchmarks are not representative. Alternatively,
the action in `do_nchar` of preparing the potential error message
before being passed to `R_nchar` may be quite costly indeed.  Or the
function cannot be unswitched from the more complex width and chars
arguments by the compiler.

If I haven't missed something, would a patch be warranted?

SEXP Cnchar(SEXP x) {
   R_xlen_t N = xlength(x);
   SEXP ans = PROTECT(allocVector(INTSXP, N));
   int * restrict ansp = INTEGER(ans);

   // Ignoring NA to avoid the branch has a very small
   // impact on performance.
   for (R_xlen_t i = 0; i < N; ++i) {
 SEXP sxi = STRING_ELT(x, i);
 if (sxi == NA_STRING) {
   ansp[i] = NA_INTEGER;
   continue;
 }
 ansp[i] = length(sxi);
   }
   UNPROTECT(1);
   return ans;
}

x <- rep_len(c(as.character(c(5L, 1:1e6)), NA_character_, 1e6:15e5), 
1e7)

Cnchar(x)
90ms
nchar(x, type = "bytes")
2500 ms

__
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

2021-04-15 Thread Ivan Krylov

Hello Ryan,

Sorry for not responding right away -- it took me a while to remember
what I meant back then :)

On Fri, 9 Apr 2021 23:34:13 +
Ryan Novosielski  wrote:

> 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_EvalDepth
> $1 = 2729
> (gdb) print R_Expressions
> $2 = 5000
> (gdb) print R_CStackStart
> $3 = 140737488207872
> (gdb) print R_CStackLimit
> $4 = 7969177

> [novosirj@amarel-test2 bin]$ ulimit -s
> 8192

So far I can only say that you get the same ulimit -s of 8192 and
R_CStackLimit of 8192 * 1024 * .95 that I get on my current machine
(and now it's the stack size limit that's reached first, not expression
depth limit). Let's try to get more information.

When you get the SIGSEGV,

1) What does print $_siginfo._sifields._sigfault show? Try printing at
least $_siginfo if the first command gives you an error.

2) When you get the crash, is the body argument accessible? What does
print *body show?

3) What are the addresses of the local variables when the crash
happens? Specifically, what do the following commands show:

print &codebase
print &pc
print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
print R_CStackDir * (R_CStackStart - (uintptr_t)&pc)

-- 
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

2021-04-15 Thread Ryan Novosielski

> On Apr 15, 2021, at 10:35 AM, Ivan Krylov  wrote:
> 
> Hello Ryan,
> 
> Sorry for not responding right away -- it took me a while to remember
> what I meant back then :)

There was a long pause there, as I didn’t get to try out those debugging 
instructions from Frederik right away. They worked great Happy for any 
assistance whenever I can get it! Thanks!

Was able to get all of that output, though I wish I had a clue what any of it 
meant. Let me know if there’s other stuff that would be helpful.

I should probably note that I’m running this as: ./R -d gdb-ia from within 
$BUILDIR/bin. gdb-ia appears to be the Intel copy of gdb (they had their own 
debugger but eliminated it sometime back).

> So far I can only say that you get the same ulimit -s of 8192 and
> R_CStackLimit of 8192 * 1024 * .95 that I get on my current machine
> (and now it's the stack size limit that's reached first, not expression
> depth limit). Let's try to get more information.
> 
> When you get the SIGSEGV,
> 
> 1) What does print $_siginfo._sifields._sigfault show? Try printing at
> least $_siginfo if the first command gives you an error.

(gdb) print $_siginfo._sifields._sigfault
$1 = {si_addr = 0x7f7fecf8, _addr_lsb = 0, _addr_bnd = {_lower = 
0x9215f829ff58, _upper = 0x7f7fecf8}}

> 2) When you get the crash, is the body argument accessible? What does
> print *body show?

(gdb) print *body
$2 = {sxpinfo = {type = 21, scalar = 0, obj = 0, alt = 0, gp = 0, mark = 0, 
debug = 0, trace = 0, spare = 0, gcgen = 0, gccls = 0, 
named = 4, extra = 0}, attrib = 0x16fa4f0, gengc_next_node = 0x3eb7710, 
gengc_prev_node = 0x3eb7780, u = {primsxp = {offset = 44368248}, 
symsxp = {pname = 0x2a50178, value = 0x1b66098, internal = 0x16fa4f0}, 
listsxp = {carval = 0x2a50178, cdrval = 0x1b66098, 
  tagval = 0x16fa4f0}, envsxp = {frame = 0x2a50178, enclos = 0x1b66098, 
hashtab = 0x16fa4f0}, closxp = {formals = 0x2a50178, 
  body = 0x1b66098, env = 0x16fa4f0}, promsxp = {value = 0x2a50178, expr = 
0x1b66098, env = 0x16fa4f0}}}

> 3) What are the addresses of the local variables when the crash
> happens? Specifically, what do the following commands show:
> 
> print &codebase
> print &pc
> print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
> print R_CStackDir * (R_CStackStart - (uintptr_t)&pc)

(gdb) print &codebase
$3 = (BCODE **) 0x7f7ff360
(gdb) print &pc
$4 = (BCODE **) 0x7f7ff358
(gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
$5 = 18446744073701307232
(gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&pc)
$6 = 18446744073701307224

--
#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] problem adding gdb to RTOOLS40 on Windows

Re: [Rd] problem adding gdb to RTOOLS40 on Windows

Re: [Rd] problem adding gdb to RTOOLS40 on Windows

Re: [Rd] nchar(x, type = "bytes") seems slower than it could be

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

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

6 matches

Site Navigation

Mail list logo

Footer information