On Wed, 2010-11-24 at 12:12 -0500, ivo welch wrote: > I just figured out what is happening. The root drive (presumably OSX > virtual memory) becomes depleted. The error message about "memory not > mapped" was a hint, too. So, not really R's fault. However, I wonder
It still may be R's fault. This segfault occurs because R (or third party code called by R) attempts to access memory beyond what is allocated/mapped. It's very likely a programming error. A bug report is warranted, subject to Duncan's earlier comments. Does the segfault only occur when a memory limit is reached? The top five functions in your traceback (below) are all defined in the base package... -Matt *** caught segfault *** address 0xdc3f9b48, cause 'memory not mapped' Traceback: 1: rep.int(seq_len(nx), rep.int(rep.fac, nx)) 2: rep.int(rep.int(seq_len(nx), rep.int(rep.fac, nx)), orep) 3: expand.grid(seq_len(nx), seq_len(ny)) 4: merge.data.frame(d, ss) 5: merge(d, ss) 6: valid.range(opt) 7: eval.with.vis(expr, envir, enclos) 8: eval.with.vis(ei, envir) 9: source("fut-into-opts.R") > whether R can be made to abort more gracefully, or at least trap the > error message and translate it into something more meaningful ("you > have run out of [virtual] memory when executing 'R statement' "). of > course, this may not be possible at all. > > /iaw > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Matthew S. Shotwell Graduate Student Division of Biostatistics and Epidemiology Medical University of South Carolina ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel