similar to: creating a long list puts R in a state where many things stop working

The following code crashes after about 300 iterations on my?x86_64-w64-mingw32?machine on R 3.5.2 --vanilla.?? Others have duplicated this (see?https://github.com/tidyverse/magrittr/issues/190?if necessary), but I don't know how machine/OS-dependent it may be.?? If it doesn't crash for you, please try increasing the length of the x vector. Substituting the commented-out line for the one

Valgrind (without gctorture) reports memory misuse: % R --debugger=valgrind --debugger-args="--leak-check=full --num-callers=18" ... > x <- 1:200000 > y <- rep(letters[1:5], length(x) / 5L) > for (i in 1:1000) { + # x[y == 'a'] <- x[y == 'b'] + x <- `[<-`(x, y == 'a', x[y == 'b']) + cat(i, '') + } 1 2 3 4 5 6 7 8 9 10

I think there is a memory bug in `substr` that is triggered by a UTF-8 corner case: an incomplete UTF-8 byte sequence at the end of a string.? With a valgrind level 2 instrumented build of R-devel I get: > string <- "abc\xEE"??? # \xEE indicates the start of a 3 byte UTF-8 sequence > Encoding(string) <- "UTF-8" > substr(string, 1, 10) ==15375== Invalid read of

?I've hit a roadblock debugging a new update to the survival package.?? I do debugging in a developement envinment, i.e. I don't create and load a package but rather? source all the .R files and dyn.load an .so file, which makes things a bit easier. ? Running with R -d "valgrind --tool=memcheck --leak-check=full" one of my test files crashes in simple R code a dozen lines

Hi, I have a R program that call a C function. I define a vector of pointer as int nLC=3; int pownLC = nLC*nLC double *MatCovExtra[nT+1]; for(k=0;k<K+1;k++) { MatCovExtra[k] = (double*)R_alloc(pownLC, sizeof(double)); } where nT>K. Then i put some values on the vector associated with the pointer: for(k=0;k<K+1;k++) { for(i=0;i<nLC;i++)

Hi, This problem started as of r73472 ("Merged in the rest of the basic ALTREP framework."); I tested r73471 and it did not exist. I'm building R devel on Ubuntu 16.04.3 LTS (64-bit), with the following flags: CC="gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer" CFLAGS="-fno-omit-frame-pointer -g -O2 -Wall -pedantic -mtune=native" and using

I haven't done any R memory debugging lately, but https://www.mail-archive.com/rcpp-devel at lists.r-forge.r-project.org/msg10289.html shows how I used to have gdb break where valgrind finds a problem so you could examine the details. Also, running your code after running gctorture(TRUE) can help track down memory problems. -Bill On Wed, Feb 7, 2024 at 12:03?PM Therneau, Terry M., Ph.D.

Mike Stump wrote: > On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to be >> able to annotate our generated C code with, for example, (var != >> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the LLVM optimizers. >>

On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > As part of our PHP compiler (phpcompiler.org), it would be great to be > able to annotate our generated C code with, for example, (var != > NULL), or (var->type == STRING), and have that information passed > around (esp interprocedurally at link-time) by the LLVM optimizers. For some odd reason I was thinking this was going to be

On an azure centos VM, I can reproduce this bug which reports either: *** caught segfault *** address 0x70000006a, cause 'memory not mapped' (crash) Or incompatible types (from builtin to integer) in subassignment type fix (no crash) Like Gabriel, I could not reproduce the bug on a mac laptop. Both R versions 3.5.1. Travers On Wed, Feb 27, 2019 at 9:08 AM William Dunlap via R-devel

Hi, I'm interested in whether or not there is a way of providing source-level annotations to help LLVM with optimizations, similar to VisualC++'s __assume facility (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). As part of our PHP compiler (phpcompiler.org), it would be great to be able to annotate our generated C code with, for example, (var != NULL), or (var->type ==

Hi, I have a long numeric vector 'xx' and I want to use sum() to count the number of elements that satisfy some criteria like non-zero values or values lower than a certain threshold etc... The problem is: sum() returns an NA (with a warning) if the count is greater than 2^31. For example: > xx <- runif(3e9) > sum(xx < 0.9) [1] NA Warning message: In sum(xx

Hi, In the man page for vector(): length: A non-negative integer specifying the desired length. Double values will be coerced to integer: supplying an argument of length other than one is an error. Since long vectors are supported, it doesn't seem to be true anymore that "double values will be coerced to integer": > bigraw <-

Full_Name: John Brzustowski Version: R-devel-trunk, R-2.4.0 OS: linux Submission from: (NULL) (206.248.132.197) DESCRIPTION seek() on files larger than 2 gigabytes fails for large values of "where" on i386 linux 2.6.13 (and presumably other 32-bit unix-like platforms). e.g.: > f<-file("3gigabytefile.dat", "rb") > seek(f, 3e9, "start",

Just following up on this old thread since matrixStats 0.53.0 is now out, which supports this use case: > x <- rep(TRUE, times = 2^31) > y <- sum(x) > y [1] NA Warning message: In sum(x) : integer overflow - use sum(as.numeric(.)) > y <- matrixStats::sum2(x, mode = "double") > y [1] 2147483648 > str(y) num 2.15e+09 No coercion is taking place, so the

Thanks, fixed in R-devel (by checking validity of UTF-8 strings for substr/substring). Tomas On 03/29/2018 03:53 AM, brodie gaslam via R-devel wrote: > I think there is a memory bug in `substr` that is triggered by a UTF-8 corner case: an incomplete UTF-8 byte sequence at the end of a string.? With a valgrind level 2 instrumented build of R-devel I get: > >> string <-

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 6 Jun 2017 09:45:44 +0200 writes: >>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Fri, 2 Jun 2017 04:05:15 -0700 writes: >> Hi, I have a long numeric vector 'xx' and I want to use >> sum() to count the number of

Hi everyone, I'm trying to get debug information for a C/pthreads application, but it seems like clang/LLVM are producing limited & erroneous debugging information. I've attached a simple test example to reproduce the problem -- I'm using clang/LLVM 3.7.1 built from source on Ubuntu 14.04. I compile the attached file with: $ clang -O1 -g test.c -lpthread If I run: $ readelf

Hi all, Looking to calculate the expected mean and variance of a ratio distribution where the source distributions are gaussian with known parameters and sample values are correlated. I see (from wikipedia: http://en.wikipedia.org/wiki/ Ratio_distribution#Gaussian_ratio_distribution) that this calculation is quite involved, so I'm hoping that someone has already coded a function to

Hi Martin, Henrik, Thanks for the follow up. @Martin: I vote for 2) without *any* hesitation :-) (and uniformity could be restored at some point in the future by having prod(), rowSums(), colSums(), and others align with the behavior of length() and sum()) Cheers, H. On 01/27/2018 03:06 AM, Martin Maechler wrote: >>>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com>