From jeff.horner at vanderbilt.edu  Fri Feb  2 16:00:29 2007
From: jeff.horner at vanderbilt.edu (Jeffrey Horner)
Date: Fri, 02 Feb 2007 09:00:29 -0600
Subject: [Rd] SEXP i/o, .Call(), and garbage collection.
In-Reply-To: <38c08c270702011022k2b15e80fl1cac5eef32eeb882@mail.gmail.com>
References: <38c08c270702011022k2b15e80fl1cac5eef32eeb882@mail.gmail.com>
Message-ID: <45C3520D.1030205@vanderbilt.edu>

K. B. Udaya wrote:
> Apologies for any obtuseness in the following.  We have been working
> on Version 2.0 of the randomSurvivalForest CRAN package and we're
> encountering a perplexing 'memory not mapped' segfault that we believe
> is "influenced" by GC.
[...]
> We are wondering if there is something fundamentally missing in our
> understanding of the interaction between R and C via SEXP objects,
> memory allocation, persistency, and any potential garbage collection
> that may be occurring.  Any comments would be greatly appreciated.
> 
> Our environment is as follows, though we have seen the same behaviour
> on an SGI Altix system, a Mac OS X (Intel) system, and with R 2.3.0:

If you can run your code on linux (x86, amd64, ppc32, or ppc64), then 
consider using valgrind for catching memory access problems. You would 
need to recompile R with debugging support (-g) and it would be best to 
compile without optimizations (although -O1 seems to be tolerated).

And running R within valgrind is as simple as:

R -d valgrind --vanilla < script.R

or even interactively with:

R -d valgrind

Best,

Jeff
-- 
http://biostat.mc.vanderbilt.edu/JeffreyHorner



[Rd] SEXP i/o, .Call(), and garbage collection.
Jeffrey Horner