similar to: can't find array overruns (was: help debugging segfaults)

(Sorry for the cross-post--- I wasn't sure which list is more appropriate...) Hi everyone, I've run into segfaults when using my randomForest package on large dataset (e.g., 100 x 15200) and large number of trees (e.g., ntree=7000 and mtry=3000). I'm wondering if anyone can give me some hints on where to look for the problem. The randomForest package mainly consists of two things:

(Sorry for the cross-post--- I wasn't sure which list is more appropriate...) Hi everyone, I've run into segfaults when using my randomForest package on large dataset (e.g., 100 x 15200) and large number of trees (e.g., ntree=7000 and mtry=3000). I'm wondering if anyone can give me some hints on where to look for the problem. The randomForest package mainly consists of two things:

Hi all, Thanks to Prof. Ripley, Prof. Gentleman, and Simon Wood (did I miss anyone?). The problem seemed to have gone away. Everyone suggested using some malloc debugger (such as Electric Fence). All I did was following half of what BDR suggested below, i.e., changing all the S_alloc() calls to Calloc() and Free(). I didn't get to try efence, and the problem seems to have disappeared! As

Hi all, Reading the wikipedia page on R, I stumbled across the following: http://fluff.info/blog/arch/00000172.htm It does seem interesting that the C execution is that much slower from R than from a native C program. Could any of the more technically knowledgeable people explain why this is so? The author also have some thought-provoking opinions on R being no-good and that you should write

Hi I have the feeling, that the argument stringsAsFactors has no impact in the function expand.grid: a <- c("PR", "NC", "A2", "BS") b <- c(1, 0.5, 0.25, 0.125, 0.0625, 0.03125) class(expand.grid(css, fscs, stringsAsFactors=FALSE)[[1]]) [1] "factor" class(expand.grid(css, fscs, stringsAsFactors=TRUE)[[1]]) [1] "factor" Also, when

Dear expeRts, The order in which the variables vary in expand.grid() is often unintuitive. I would like to suggest a 'method' slot for expand.grid() which requires only very little changes (100% backward compatible) and which allows one to control this order. Please find attached diffs against R-devel. Cheers, Marius ### ./src/library/base/R/expand.grid.R

Commit-ID: 9b625887a59c03c244b43550b576529f209dde11 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=9b625887a59c03c244b43550b576529f209dde11 Author: H. Peter Anvin <hpa at linux.intel.com> AuthorDate: Tue, 5 Jan 2016 16:43:50 -0800 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 16:43:50 -0800 [klibc] i386: remove special

Hello! I was wondering if it's possible to see the actual code of checkTmvArgs function that is part of the code for rtmvnorm (which is below - I just typed "rtmvnorm" on the prompt). I get an error: Error in checkTmvArgs(mean, sigma, lower, upper) : sigma must be a symmetric matrix At the same time I am pretty sure that the matrix I am passing as sigma is a var-covar matrix

Commit-ID: cf8147c43a60d9eb6a6713d16f30364a698a6936 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=cf8147c43a60d9eb6a6713d16f30364a698a6936 Author: H. Peter Anvin <hpa at linux.intel.com> AuthorDate: Tue, 5 Jan 2016 18:31:40 -0800 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 18:35:16 -0800 [klibc] Add accept4(), handle

Hello, JIT compiler interferes with internal R completions: compiler::enableJIT(2) utils:::functionArgs("density", '') gives: utils:::functionArgs("density", '') Note: no visible global function definition for 'bw.nrd0' Note: no visible global function definition for 'bw.nrd' Note: no visible global function definition for 'bw.ucv'

I initially sent this to the biocore mailing list - but it was suggested that r-devel would also find it interesting. Many of us use a macro like #define CALL_DEF(fname, nargs) { #fname, (DL_FUNC)&fname, nargs} for use in function registration for use with .Call. For example, using the example from R Extension manual, if we want to register a C function myCall with three arguments, we

In R's sprintf() if any of the arguments has length 0 the function aborts. E.g., > sprintf("%d", integer(0)) Error in sprintf("%d", integer(0)) : zero-length argument > sprintf(character(), integer(0)) Error in sprintf(character(), integer(0)) : 'fmt' is not a non-empty character vector This comes up in code like x[nchar(x)==0] <-

The survival package, like many others, has several helper functions that are not declared in the namespace, since their only use is to be called by other "main" functions of the package.? This works well since the functions in the survival namespace can see them --- without ::: arguments --- and others don't. Until a situation I ran into this week, for which I solicit comments

I am writing a function to work with class I am defining. I have a question about using nargs() inside of parentheses function. nargs() shows the same for supplying 1 argument, or no arguments at all. Here is a small example: > "[.myclass"<-function(x,...) print(nargs()-1) > x<-c(1,2,3) > class(x)<-"myclass" > x[] [1] 1 > x[1] [1] 1 > x[1,2] [1] 2

Hi, is there an easy, robust, and/or recommended way to distinguish a missing argument from an empty argument as in: foo <- function(i, j){ print(missing(j)) print(nargs()) } foo(i) # TRUE, 1 foo(i,) # TRUE, 2 I know I can work around with nargs, the list of arguments and the names of the passed arguments, but I wish there is something already in place for this. This is

Hello everybody, I've run into some strange behavior with memory sanitizer that I can't explain and hope somebody with more knowledge of the implementation would be able to help me out or at least point me into the right direction. For background, I'm using memory sanitizer to check Julia (julialang.org), which uses (or at least will once I track down a few bugs) MCJIT for the code

I assume there are transitions between JITted code and native helper functions. How are you handling them? Are native functions MSan-instrumented? MSan is passing shadow across function calls in TLS slots. Does your TLS implementation guarantee that accesses to __msan_param_tls from JITted and from native code map to the same memory? On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov

I have verified that both TLS implementations indeed find the same area of memory. Anything else I could look for? On Tue, Jan 28, 2014 at 4:28 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > Yes, both JIT code and the native runtime are instrumented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are

>From an example in http://www.uni-muenster.de/ZIV.BennoSueselbeck/s-html/helpfiles/nargs.html , number of arguments in '...' can be obtained by (function(...)nargs())(...) . I now realize that sys.call() doesn't expand '...' when the function is called with '...'. It just returns the call as is. If 'stopifnot' uses sys.call() instead of match.call() , the

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the