similar to: Forcing a PROTECT Bug to Occur

I'm trying to learn about R's PROTECT system. To that end I've tried to create an example of C code that doesn't protect anything. I was hoping it would either segfault from trying to access deallocated memory, or maybe print out nonsense results because the unprotected memory got overwritten, but I can't make either happen. Here's my current code (all in R, using the

Hello, I call a function via .Call passing to it a raw vector(D) and an integer(I) The vector is a series K1,KData1, V1,VData1, K2, KData2, ... where the integer K1 is the length of Data1 and similarly for Ki (wrt Datai)(similarly for V*) There 2*I such pairs( (Ki,KDatai), (Vi,VDatai)) The numbers Ki(and Vi) are written in network order. I am returning a list of I elements each element a

Dear Developers, I've been struggling through writing R extension in C. I've been using an external pointer to store my data (please see sample below). I encountered a very weird erroneous behaviour: when I tried to use my external pointer to a structure holding several types of data, including SEXPs, I discovered that SEXPs change their types between returning from initialization

Hello, As this little program illustrates, duplicating a STRSXP does not seem deep enough. require( inline ) fx <- cfunction( signature( x = "character"), ' SEXP y = PROTECT( duplicate( x ) ); int n = LENGTH(x); int nc = 0 ; char* p = 0 ; for( int i=0; i<n; i++){ p = (char*)( CHAR( STRING_ELT( y , i ) ) ); nc = strlen( p ) ; for( int j=0; j<nc; j++){ p[j] =

The Bioconductor build for a package DirichletMultinomial on R Under development (unstable) (2013-02-26 r62077) -- "Unsuffered Consequences" at http://bioconductor.org/checkResults/devel/bioc-LATEST/DirichletMultinomial/george2-buildsrc.html shows * creating vignettes ... ERROR ... Error: processing vignette ?DirichletMultinomial.Rnw? failed with diagnostics: chunk 21 (label

This is a followup to the R-help thread, "Error: STRING_ELT() can only be applied to a 'character vector', not a 'builtin'". Thanks to Prof. Brian Ripley for suggesting the use of gctorture and valgrind. I am getting segmentation faults that appear to come from a memory leak. I now have a reproducible example (below). It requires the "g.data" package

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

For using R's .Call interface to C functions, all the examples I've seen have the C function return type SEXP. Why? What does R actually do with this return type? What happens if I *don't* return a SEXP? Reason I ask, is I've written some R code which allocates two long lists, and then calls a C function with .Call. My C code writes to those two pre-allocated lists, thus, I

Dear developers: I have just came across an (unexpected to me) behaviour of lists when assigning NULLs to list elements. I understand that a NULL is a valid R object, thus assigning a NULL to a list element should yield exactly the same result as assigning any other object. So I was surprised when assigning a NULL in fact removed the element from the list. Is this an intended behaviour? If

I have a few simple questions about the usage of PROTECT, more specifically how careful one needs to be. Simple yes/no answers are fine. Most of the uses I have seen do protection when memory is allocated. But what if one just want to assign a value of another function to a variable. Say eg. that foo is a function that returns a SEXP. Would the following code be fine? SEXP bar;

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

Hi Everyone, At the end of this email is a transcript of a problem I have found in RODBC version 2.3-1. It appears that the bug fix in odbcClose for the memory leak has meant that the garbage collector is falling over when it tries to free up the extPtr attribute of the RODBC connection pointer. Any advice on how to fix this? Thanks for your help, Tom

Hi folks, I apologise if this is in the documentation somewhere, but I can't seem to find it. I also did a search of CRAN without any success. I'm using R-1.8.1 (pre-compiled) on Windows 2000 with Rtools and mingw 2.0.0 (which includes gcc/g++ 3.2). I'm trying to link some C++ code from another application to R using the .Call interface and am experiencing some problems. I was

Prof. Ripley, > From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] [snipped...] > R cannot currently make use of anyone else's LAPACK routines (because > we've found too many problems with them). > > If you are getting no useful diagnostics, try > dyn.load("RHOME/modules/lapack.so"). That ought to tell you > why you can't > load it. My

Prof. Ripley, > From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] [snipped...] > R cannot currently make use of anyone else's LAPACK routines (because > we've found too many problems with them). > > If you are getting no useful diagnostics, try > dyn.load("RHOME/modules/lapack.so"). That ought to tell you > why you can't > load it. My

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.

I originally posted this to R-help, but here is probably a better place. I have a rather complex routine which works great in R. Then I bootstrap it. After running a few minutes it typically segfaults, though it happens very randomly. This happens w/ 1.9.0 and 1.9.1 on Fedora1 and a Scyld (RH7.3) system. Traces always point back to routines in src/main/memory.c, though often not the same

I'm trying to generate an R interface for a library that's commonly used and I'm currently writing wrapper functions for file i/o and return an object (list?) that contains the elements of the C structure. For example, reading a file that contains: struct CONFIG_RECORD { char coeffs_filename[256]; char species_filename[256]; unsigned long

I've trapped this segfault with gdb, but I'm not sure what it means or what to do next. Paul _____ $ R -d gdb GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is

I am trying to build R with 64bit support so I can access more than 2GB of memory on an IBM running AIX. (IBM NightHawk II RS/6000 node with 16 64-bit, 375-MHz POWER3 CPUs and 32 GB of memory, if you want specifics) The 32bit install required little tweaking, but the 64 bit is sufficiently complicated that I thought I would report my findings here and ask for help with the latest (and hopefully