From rory.winston at gmail.com  Thu Jun 13 12:55:44 2013
From: rory.winston at gmail.com (Rory Winston)
Date: Thu, 13 Jun 2013 20:55:44 +1000
Subject: [Rd] load/unload segfault puzzle
In-Reply-To: <mailman.35.1371117609.3499.r-devel@r-project.org>
References: <mailman.35.1371117609.3499.r-devel@r-project.org>
Message-ID: <7353B511-62FF-4FEA-AA9D-8BFBBD4F985D@gmail.com>

Ben

Have you compiled R form source yourself? If so, I would be tempted to mark up memory. c with some debug log statements - especially around line 1357, and possibly inside the finalizers function as it attempts to run the C finalizers....not pretty I know, but may be the quickest approach to quickly identify whats failing...
Cheers
-- Rory


> 

>  Yes, thanks -- Bill Dunlap already suggested this.  Your and Bill's
> warning about how slow gctorture makes things is correct -- I gave up
> after running for 3.5 hours when it had gotten only partway through
> loading the Matrix package; I will have to find a machine with a decent
> cooling system (i.e. not my laptop) where I can replicate the error.
>  I've just re-run the regular valgrind, with a fresh build right after
> an SVN update.  I got exactly the same results as above.  We're
> certainly *not* calling reg.finalizer() anywhere in our package, and I
> don't think Rcpp or RcppEigen or minqa do ... there looks to be some
> kind of default finalization done on the reference class objects (based
> on running 'strings' on the object files ...
>  I tried gdb'ing in and setting a breakpoint at memory.c:1357, but this
> breakpoint gets hit a lot, and I'm sort of stabbing in the dark at this
> point.
> 
>   Ben Bolker
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> R-devel at r-project.org mailing list  DIGESTED
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> End of R-devel Digest, Vol 124, Issue 12
> ****************************************



[Rd] load/unload segfault puzzle
Rory Winston