Hmm. I commited 2845 and 2846 today.

Anyway, if you see it also with 0.9.0 this means more detective work.

Le 07/01/11 15:05, Douglas Bates a écrit :
On Fri, Jan 7, 2011 at 5:34 AM, Romain Francois
<rom...@r-enthusiasts.com>  wrote:
Le 05/01/11 18:52, Douglas Bates a écrit :

I don't know whether this is through error on my part or because of an
"infelicity" in the Rcpp module code but the lme4a package, which now
uses Rcpp modules extensively, ends up with some difficult-to-trace
memory corruption issues.  Yesterday i finally bit the bullet and ran
a test with gctorture(TRUE) and valgrind enabled.  It takes a very
long time and results in a segfault when trying to load the package.
I enclose the transcript.  I should say that this is using Rcpp_0.9.0
from CRAN, not the SVN version of Rcpp.

I just got these results this morning (it was running overnight) and
haven't looked at the code in Module.cpp and cache.cpp yet.  If it
seems likely that the code is beyond me I can try to work out a
simpler example that triggers the problem.

Hi Doug,

Sorry for the delay, I'm not fully operational yet.

All this might be related to some code I put in during holidays and did not
have a chance to fully test.

Can you try with rev 2845 and let me know if you still see the problem.

Romain

Regrettably the problem persists with rev 2845 (which was from
2011-01-04, is that the one you meant?) but it is also present when
using Rcpp_0.9.0


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release


_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to