Correction: my assumption was not completely wrong. RcppOctave works
now with a minor tweak (.Call('octave_end') before terminating R). So
cleaning up the Mac OS X environment did indeed fix this issue.On Fri, Nov 1, 2013 at 4:24 PM, Dominick Samperi <[email protected]>wrote: > I assumed incorrectly that getting the pure Octave test working would > imply that > RcppOctave will work. I just checked, and I'm seeing the same memory fault > that you see. As I mentioned in the rcppoctave-users thread even the pure > Octave > test will fail (for the same reason) if it is not terminated properly, and > it appears that > the way the embedded session is terminated in RcppOctave may not be correct > in the Mac OS X environment. Further comments on this will move to > rcppoctave-users > list... > > > On Fri, Nov 1, 2013 at 3:44 PM, Simon Zehnder <[email protected]>wrote: > >> Same thing actually on my side: I had a hardware crash lately with 10.8 >> and made fresh install after formatting my harddrive NSA-style :) >> >> Afterwards I compiled R 3.0.1 and from macports the gcc48 port as well as >> gettext. Then, Mavericks came and I updated - nothing worked anymore: I >> reinstalled gcc48 port and deleted R 3.0.1. Then I installed gcc4.8.2 from >> http://hpc.sourceforge.net, Xcode Command line tools for Mavericks and >> XQuartz 4.7.2. I work with environment modules, where I can load a certain >> compiler with its needed environment variables. With gcc 4.8.2 I installed >> R-3.0.2 and then the packages. Always have to type “module load >> compilers/gcc-4.8.2 before starting R, but that doesn’t bother me … I still >> can use openMP to its great extent :) >> >> My problem is linked to the install_name_tool and the way on Mac OS paths >> are set and replaced in dynamic libraries … this could of course be caused >> by “older tools” like the llvm-gcc4.2 “laying” around…. though locate does >> not find them…. >> >> >> >> On 01 Nov 2013, at 20:33, Dominick Samperi <[email protected]> wrote: >> >> > My original attempt to update to Mavericks failed (unrelated hardware >> issue), and this >> > may have actually worked in my favor. It forced me to install Mac OS X >> 10.8 from >> > scratch, a "clean" install, that I later upgraded to Mavericks. If you >> upgraded from >> > an existing configuration you may have old tools (like llvm-g++-4.2) >> laying around >> > that could cause problems. >> > >> > >> > On Fri, Nov 1, 2013 at 3:02 PM, Simon Zehnder <[email protected]> >> wrote: >> > I read through all the thread answers and my variables in the Makeconf >> are the same alsso I installed the Xcode Command Line Tools for Mavericks. >> Are there any other apps and libs that have been to be updated? (I do not >> use brew). What remains is the following: >> > >> > Compiling Rcpp give the pointer exception (when calling >> compileAttributes), also encountered in the thread you referred to. >> > >> > Compiling Rcpp and adding the flag “-headerpad_max_install_names” lets >> the compileAttributes function do its work without any exception. My next >> guess is: possibly the gettext library… >> > >> > Best >> > >> > Simon >> > >> > On 01 Nov 2013, at 19:20, Dominick Samperi <[email protected]> wrote: >> > >> > > In your original post you mention the "pointer being freed was not >> allocated" error message. I have just tracked this down in another context >> (Octave >> > > under Mac OS X). In my case the error occurs on the dlopen() call for >> > > an R package shared library. The fix was to make sure all apps and >> libs >> > > are updated after moving to Mavericks. See the thread in >> rcppoctave-users >> > > list for a blow-by-blow description. >> > > >> > > >> > > On Fri, Nov 1, 2013 at 1:11 PM, Simon Zehnder <[email protected]> >> wrote: >> > > You are right, working with apple and C++ is often a mess. Up to now, >> llvm does not yet support openmp. It is coming but I do not see it fully >> implemented before next summer. If I want to use openmp I have thus to rely >> on the gcc which brings a lot of problems with it and from what I read on >> the R-lists most of the Mac Users suffer. I guess that this time a >> reinstall of R was unavoidable for most of us. I thought about using the >> xcrun —find gcc/g++ etc. to get what is needed in a Makevars but this does >> not give anything so far. >> > > >> > > >> > > On 01 Nov 2013, at 17:50, Dominick Samperi <[email protected]> >> wrote: >> > > >> > > > With Apple moving from gcc/g++ to LLVM/clang++ I guess it makes >> sense >> > > > for R/Rcpp to use the LLVM/clang++ tool chain eventuallly, but I >> don't know >> > > > if there are plans to do this. Otherwise, the R community would >> need to >> > > > support "MACtools" following the model provided by "Rtools" under >> Windows... >> > > > >> > > > >> > > > On Fri, Nov 1, 2013 at 12:12 PM, Simon Zehnder < >> [email protected]> wrote: >> > > > Hi Dominick, >> > > > >> > > > I did install files from brew but instead used the gcc from >> http://hpc.sourceforge.net >> > > > >> > > > >> > > > On 01 Nov 2013, at 16:55, Dominick Samperi <[email protected]> >> wrote: >> > > > >> > > > > If you depend on tools installed using brew, you might want to try >> > > > > removing those that were installed before the Mavericks update, >> > > > > using: >> > > > > rm -rf /usr/local/Cellar >> > > > > brew prune >> > > > > brew doctor >> > > > > brew install <what-you-need> >> > > > > >> > > > > >> > > > > On Fri, Nov 1, 2013 at 11:19 AM, Simon Zehnder < >> [email protected]> wrote: >> > > > > Point landing J.J.! >> > > > > >> > > > > I already compiled a new R when Mavericks came out with a newly >> installed a gcc-4.8.2, that I can load via environment modules. I also >> installed the Xcode Command Line Tools for Mavericks. >> > > > > >> > > > > I now reinstalled Rcpp with the gcc-4.8.2 and threw away all >> object and shared-object files in my /src/ folder of my package. The >> problem remains. Is there something special I can look for in my Makeconf >> file? What is so different about ‘compileAttributes’ in contrast to >> ‘sourceCpp’ or a usual package compilation via R CMD INSTALL? Does >> compileAttributes uses some additional flags and/or libraries? >> > > > > >> > > > > Best >> > > > > Simon >> > > > > >> > > > > >> > > > > >> > > > > On 01 Nov 2013, at 15:56, JJ Allaire <[email protected]> >> wrote: >> > > > > >> > > > > > Are you by any chance on OS X Mavericks? I had one other user >> report this specific error on Mavericks and it seemed to be related to the >> use of different compilers (and thus different heaps) within the same >> compilation (there is exposure to this with the changes made by Apple to >> the toolchain in Mavericks). >> > > > > > >> > > > > > J.J. >> > > > > > >> > > > > > >> > > > > > On Fri, Nov 1, 2013 at 10:01 AM, Simon Zehnder < >> [email protected]> wrote: >> > > > > > Dear Rcpp::Users and Rcpp::Devels, >> > > > > > >> > > > > > I get a weird exception when I try to compile an attribute in >> one of my packages: >> > > > > > >> > > > > > compileAttributes("/Users/simonzehnder/git/mmstruct/mmstruct/") >> > > > > > R(6256,0x7fff79ad9310) malloc: *** error for object >> 0x7fff7ac48330: pointer being freed was not allocated >> > > > > > *** set a breakpoint in malloc_error_break to debug >> > > > > > Abort trap: 6 >> > > > > > >> > > > > > If I instead use the sourceCpp function all works fine: >> > > > > > >> > > > > > >> sourceCpp("/Users/simonzehnder/git/mmstruct/mmstruct/src/testing.cpp”) >> > > > > > testfunction_cc(c(0,0,0), list(trades = rnorm(10), T = 360)) >> > > > > > [1] 0.000000e+00 3.509927e-05 1.169976e-05 >> > > > > > >> > > > > > The function in my file is actually pretty simple (and its the >> only one): >> > > > > > >> > > > > > #include<Rcpp.h> >> > > > > > >> > > > > > // [[Rcpp::export]] >> > > > > > >> > > > > > Rcpp::NumericVector testfunction_cc(Rcpp::NumericVector par, >> > > > > > Rcpp::List list) >> > > > > > { >> > > > > > const unsigned int K = par.size(); >> > > > > > Rcpp::NumericVector trades = list["trades"]; >> > > > > > const unsigned int T = list["T"]; >> > > > > > double tmp = mean(trades)/T; >> > > > > > std::vector<double> startp(K); >> > > > > > startp[0] = 0.0; >> > > > > > startp[1] = tmp * 0.75/2; >> > > > > > startp[2] = tmp * 0.25/2; >> > > > > > >> > > > > > return Rcpp::wrap(startp); >> > > > > > } >> > > > > > >> > > > > > At this moment I am a little perplexed. Where should I search >> for a possible error? What are things to try out? >> > > > > > >> > > > > > Best >> > > > > > >> > > > > > Simon >> > > > > > >> > > > > > _______________________________________________ >> > > > > > Rcpp-devel mailing list >> > > > > > [email protected] >> > > > > > >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> > > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > Rcpp-devel mailing list >> > > > > [email protected] >> > > > > >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> >> >
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
