similar to: (PR#7826) segfault during build of 2.1.0 on RH9; print.POSIXct

In attempting to build R using rpmbuild --rebuild R-2.1.0-0.fdr.2.fc3.src.rpm on a fairly up-to-date RedHat 9 system (that is, with patches installed through May 1 2004), it failed at the make check-all step. The problem was reproducible by going into the tests directory and make test-Segfault The last lines of the saved file no-segfault.Rout.fail are > > ## c.POSIXct : > >

In attempting to build R using rpmbuild --rebuild R-2.1.0-0.fdr.2.fc3.src.rpm on a fairly up-to-date RedHat 9 system (that is, with patches installed through May 1 2004), it failed at the make check-all step. The problem was reproducible by going into the tests directory and make test-Segfault The last lines of the saved file no-segfault.Rout.fail are > > ## c.POSIXct : > >

Dear Peter, Thank you very much for your kind and helpful reply. As I mentioned in a followup email to r-bugs, indeed, one aspect of this issue is a (user specified) shorter stack than that expected by R -- I had only allowed 1 MB of stack space a long long time ago, and forgotten about it. Due to a glitch with r-bugs@r-project.org, I ended up submitting this bug twice, and your original

Thank you, Jskud. I can reproduce your problem, though not the seg.fault, see below >>>>> "Jskud" == Jskud <Jskud@Jskud.com> >>>>> on Sat, 30 Apr 2005 09:04:03 +0200 (CEST) writes: Jskud> In attempting to build R using rpmbuild --rebuild Jskud> R-2.1.0-0.fdr.2.fc3.src.rpm Jskud> on a fairly up-to-date RedHat 9 system (that

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

>>>>> "VW" == Viechtbauer Wolfgang (STAT) <Wolfgang.Viechtbauer at STAT.unimaas.nl> >>>>> on Fri, 26 Sep 2008 18:00:19 +0200 writes: VW> Hi all, I'm trying to fit a marginal (longitudinal) VW> model with an exponential serial correlation function to VW> the Orange tree data set. However, R crashes frequently VW>

If anyone has a few extra CPU cycles to spare, I'd appreciate it if you could verify a problem that I have encountered. Run the code below and tell me if it crashes your R before completion. library(lme4) data(bdf) dump<-sapply( 1:50000, function(i) { fm <- lme(langPOST ~ IQ.ver.cen + avg.IQ.ver.cen, data = bdf, random = ~ IQ.ver.cen | schoolNR); cat("

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));"

Dear all, I had a R segmentation fault, and then invoked debug mode and ran step by step. When I reached "terms(Y~X1*X2*...*X16)", I would then have "segmentation" fault. However, if I just ran this under regular "R interactive" mode, it would be fine though taking long time. My questions are: 1. Is there a known limit of terms for a formula? 2. Why does the

Dear all, I had a R segmentation fault, and then invoked debug mode and ran step by step. When I reached "terms(Y~X1*X2*...*X16)", I would then have "segmentation" fault. However, if I just ran this under regular "R interactive" mode, it would be fine though taking long time. My questions are: 1. Is there a known limit of terms for a formula? 2. Why does the

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

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:

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

Example run and stack trace: wazor /s/src/stat/R-1.8.0/tests/Examples $ ../../bin/R --no-save < base-Ex.R R : Copyright 2003, The R Development Core Team Version 1.8.0 (2003-10-08) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a

Hi all, I ran into a segfault while playing with dates. $ R --no-init-file ... > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); d$zone=NULL; d$zone=""; d Attaching package: ?lubridate? The following object is masked from ?package:base?: date Warning message: package ?lubridate? was built under R version 3.4.0

On the documentation page for DateTimeClasses, in the Examples section, there are the following two lines: format(.leap.seconds) # the leap seconds in your time zone print(.leap.seconds, tz = "PST8PDT") # and in Seattle's The second line (using print) seems to ignore the tz argument, and prints the dates in my time zone, while: format(.leap.seconds, tz =

I'm struggling with time zone version when expressed as hours offset from GMT. Can anyone confirm that the behaviour below is incorrect? It seems that the GMT offsets are backwards: > format(as.POSIXct("2011-05-23 17:23:00", tz="Europe/London"),tz="America/New_York",usetz=T) [1] "2011-05-23 12:23:00 EDT" - this works. >

>>>>> Jennifer Lyon <jennifer.s.lyon at gmail.com> >>>>> on Thu, 15 Dec 2016 09:33:30 -0700 writes: > On the documentation page for DateTimeClasses, in the Examples section, > there are the following two lines: > > format(.leap.seconds) # the leap seconds in your time zone > print(.leap.seconds, tz = "PST8PDT") # and in

R 2.6.1 on a Thinkpad T60 running up-to-date Gentoo: Despite the documentation, which says: 'strftime' is an alias for 'format.POSIXlt', and 'format.POSIXct' first converts to class '"POSIXlt"' by calling 'as.POSIXlt'. Note that only that conversion depends on the time zone. strftime fails on POSIXct objects: > foo <-

Don, thanks for your report. On Jan 19, 2005, at 12:41 PM, Don MacQueen wrote: > I'm encountering a problem formatting POSIXct objects in R 2.0.1 on OS > X. > > For reference, on a Solaris system, R 2.0.1 (2004-11-15), formatting > is correct: > >> Sys.time() > [1] "2005-01-19 09:12:33 PST" >> format(Sys.time(),'%H:%M %Z') > [1]