similar to: segfault when using browser() in Rprofile.site

Hi -- I'm trying to package R for inclusion on some upcoming Red Hat Powertools distribution. I have started with the 0.61 version packaged by Martyn Plummer <plummer at iarc.fr> (Thanks Martyn!) and have upgraded to 0.62-2. I have succeeded in running R demo's on i386-redhat-linux-gnu, and now I am also trying to get the alpha and sparc versions working. On sparc-redhat-linux,

Hello, I've been struggling with a problem for the past several weeks, trying to get PL/R (R procedural language handler for PostgreSQL, http://www.joeconway.com/plr/) to work on Red Hat 9. In brief, R dumps core during the embedded library initialization, while in Rf_regcomp(), working on on Rprofile. Below I've included the important parts of a backtrace: Program received signal

hi! i am experiencing the same behaviour explained here: http://finzi.psych.upenn.edu/R/Rhelp02/archive/2482.html (i copied the message below) has anybody found a solution? here is the code that gives me a segmentation fault library(Rdbi) library(Rdbi.PgSQL) conn <- dbConnect(PgSQL(), dbname = "PGA") tmp <- "create table test ( expid int, name varchar(128));"

The released version of R-1.7.0 builds and checks fine on Mandrake 9.1, but I am still having trouble with my vignettes and sweave causing segfaults. Unfortunately the segfaults with the release version are happening in tests where I have much more difficulty trapping them. I did also build R-1.7.0beta_2003-04-16 this morning, and for that the segfaults occurred in a test which is much easier for

R's dyn.unload() will unconditionally unload the given shared object; it does not check whether there is any object (external pointer or weak reference) with a C finalizer pointing into the space of the shared object being unloaded. So it is expected that R will segfault later when such finalizer is run. Currently there is no other way than to handle this on the side of the shared

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

Dear R-devel - I have investigated the report I made at https://stat.ethz.ch/pipermail/r-devel/2008-May/049683.html some more, and believe I have enough information to warrant an update. My sessionInfo() immediately after starting R is at the bottom of this message. I decided to first concentrate on finding out why I sometimes receive a segfault while closing a graphics window while the

Hi all, I'm not sure if I'm not supposed to do the following (the dyn.unload part, I mean) or this could be a bug (in R or Rcpp): ``` Rcpp::sourceCpp(code=' #include <Rcpp.h> class Object {}; //[[Rcpp::export]] SEXP new_object() { return Rcpp::XPtr<Object>(new Object()); }' ) new_object() dyn.unload(list.files(tempdir(), ".(so|dll)$",

Below is a gdb bt from a segfault provoke by my vignette for dse2. This seems to be relatively reproducible in the sense that I got a segfault three times (without gctorture) on Mandrake 9.0 and also caught it in Mandrake 9.1, at what looks to my untrained eye to be about the same place (actual at connections.c:293 in Mandrake 9.1). This is the build from Friday morning. Paul Gilbert

Hello, I get a segfault when running glmmboot in my own package glmmML. Has happened many time before, but this time I get no hint of where in my C functions the error might be. I give the output below. Can this be an R bug? I suspect it has to do with repeated calls to 'vmmin' like this: for (...){ vmax = vmaxget(); vmmin(*p, b, &Fmin, bfun,

This problem is with R 1.7.0 (as released) on Linux and Solaris. Details below are from Linux, Mandrake 9.1. The problem also happened with R 1.6.2 and on Mandrake 9.0. Vignettes often (for me) provokes problems with the misleading error message: * creating vignettes ... ERROR Error in sub(pattern, replacement, x, ignore.case, extended) : invalid argument Error in buildVignettes(dir =

one more bit of information about this problem. If I start R as the user "postgres" i dont have the segmentation fault. ---------- Forwarded message ---------- Date: Wed, 5 Feb 2003 19:19:39 -0500 (EST) From: Rafael A. Irizarry <ririzarr at jhsph.edu> Reply-To: rafa at jhu.edu To: "R-Help (E-mail)" <r-help at r-project.org> Subject: rdbi segmentation fault hi! i

A common need in R frontends is to provide some sort of read, (parse), evaluate, print loop. However, there are also a number of points where frontends may want to differ from the standard REPL as available e.g. in R_ReplDLLdo1(). First some thoughts on what is needed, and what is already there, or missing. If you want to skip over this, a short summary is provided in the second half, below

Full_Name: Murray Stokely Version: 2.10.1 OS: Linux Submission from: (NULL) (216.239.45.4) The Defn.h header includes limits.h for PATH_MAX and then checks if it hasn't been defined and if not sets something manually. Some of the R code uses PATH_MAX but a lot of other functions in unix/sys-unix.c and main/startup.c just hardcodes a limit of 256 characters. In my environment this is not

I recently built R 1.6.2 on solaris 2.8 with gcc 3.2. Things seem to run OK, but using graphics causes R to core dump. (For instance, by using the plot() or hist() functions.) Sometimes I can see the graphics drawn before it actually core dumps. The core file shows a crash in Rf_gpptr. I'm quite new to R, so I don't know what info would be helpful for diagnosis. I'm including

Hi, [System info: R 1.6.1 compiled from source (no args to configure) on Redhat 7.1 Linux i/386] I have some spatial statistics programs that recently (since R 1.6.1) have generated SIGSEGV. These R programs use the splancs library as well as some C code of my own for Voronoi analysis. The program has a big loop to fit various model parameters against a spatial distribution of biological

I did some poking around with GDB and confirmed that the advice of setting R_CStackLimit after init, which is echoed in the "threading issues" section of the R-exts help document, isn't entirely useful because init apparently loads the main package which trips over the broken stack checking. Stack trace: #0 R_SignalCStackOverflow (usage=140732197147604) at errors.c:81 #1

Ben, Thanks for the bug report. I am off two minds about it as discussed below. But as it does indeed create a crash / segfault, I am passing this on to the R bug tracker. A suggested two-line patch is below; I tested the patch against a 'vanilla' 2.6.1 source tree. On 6 December 2007 at 19:32, Ben Goodrich wrote: | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | Package:

Hello all I'm coming late to this discussion, and my comments may now be beside the point-- but I have been intending to ask what people think of the pros & cons of internal and external (e.g. 'debug' package) debuggers. When I wrote 'debug', the internal debugger just didn't do what I wanted, but maybe things have changed-- hence this email, to find out. The

I would say this was user error (insisting on editing non-existent rownames), although the argument is documented. You could argue that there are implicit rownames, but they would be 1, 2 ... not row1, row2 .... And rownames(mat) is NULL. For an interactive function the best solution seems to be to throw an error when the user asks for the impossible. I'll fix it for 2.7.0: it