Valgrind error inv_sympd #72
Comments
|
Thanks for all that work. The issue might be your use of |
|
Here is a one-file version of your code. When you #include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
using namespace Rcpp;
// [[Rcpp::export]]
NumericMatrix arma_inv(const arma::mat& X) {
// this works fine
arma::mat res = arma::inv(X);
return wrap(res);
}
// [[Rcpp::export]]
NumericMatrix arma_inv_sympd(const arma::mat& X) {
// this gives errors in valgrind
arma::mat res = arma::inv_sympd(X);
return wrap(res);
}
/*** R
##library(debugpkg)
set.seed(123)
X <- crossprod(matrix(rnorm(25),5,5))
# this works fine
arma_inv(X)
# this works seeminly fine but valgrind gives an error
arma_inv_sympd(X)
*/ |
|
And here is the program running above on my Linux 64 bit system with the same Valgrind call and no issues: |
|
Could you try an R built with system LAPACK too, please? I use the Michael Rutter builds on Ubuntu which correspond to my Debian packages. Either variant should be fine. You can even try Docker... (Congrats by the way on getting seqHMM onto CRAN. Looks like a great package I should take a closer look at.) |
|
Oh, missed that:
If you need help building R on RH let me know. It's been several years since I needed to use those repos. Are you using a prebuilt version? In which case we should talk to the maintainer to not rely on the Rlapack build ? If it is a local build I am sure we can assist you or your sysadmin in making a better built. |
|
Yes I did use prebuilt R installed via yum. I now compiled latest R (3.2.3) by myself with I then compiled R with R is now configured for x86_64-pc-linux-gnu I then installed Rcpp, RcppArmadillo and all their dependencies, and RcppArmadillo states: So everything should be okay. I then ran the same valgrind script (using your "slightly" more easier way), and I again I get the same errors: I would say that there is something wrong somewhere in my own setup, but the same error was actually found by BDR in CRAN checks of seqHMM package: http://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/seqHMM-Ex.Rout: Personally this is not a big issue, I circumvented the problem by replacing Please let me know if there is something peculiar in the way I compiled R or if I should try some other configuration. |
|
Weird. We do know that the setup BDR uses often does not include a shared BLAS/LAPACK but using R's. I think we see that here as in the last block you quote, we get references to In any event, I agree with you that the quickest way forward is to stick with |
|
Here is one more variant---now standalone C++ linked against Armadillo and LAPACK. No issue. // -*- mode: C++; c-indent-level: 4; c-basic-offset: 4; compile-command: "g++ -s -Wall -O3 -o arma_sym_inv arma_sym_inv.cpp -larmadillo" -*-
// cf https://github.com/RcppCore/RcppArmadillo/issues/72
// now trying outside of R
#include <iostream>
#include <armadillo>
using namespace std;
using namespace arma;
int main(int argc, char** argv) {
arma_rng::set_seed(123);
mat A = randn<mat>(5,5);
mat B = A * trans(A);
cout << B << endl;
mat C = inv_sympd(B);
cout << C << endl;
return 0;
}
#if 0
edd@max:~/src/progs/C++$ valgrind --tool=memcheck --leak-check=full --track-origins=yes ./arma_sym_inv
==28016== Memcheck, a memory error detector
==28016== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28016== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==28016== Command: ./arma_sym_inv
==28016==
12.2741 -0.6598 -1.4571 3.8146 -2.7375
-0.6598 3.0448 -2.1492 0.5045 0.9815
-1.4571 -2.1492 4.4715 0.2012 -0.1215
3.8146 0.5045 0.2012 2.2655 -1.0930
-2.7375 0.9815 -0.1215 -1.0930 2.8287
0.5741 0.9072 0.6770 -1.3503 -0.2518
0.9072 2.2583 1.4738 -2.5629 -0.8326
0.6770 1.4738 1.2208 -1.8214 -0.5075
-1.3503 -2.5629 -1.8214 3.9434 1.0280
-0.2518 -0.8326 -0.5075 1.0280 0.7741
==28016==
==28016== HEAP SUMMARY:
==28016== in use at exit: 0 bytes in 0 blocks
==28016== total heap usage: 28 allocs, 28 frees, 138,317 bytes allocated
==28016==
==28016== All heap blocks were freed -- no leaks are possible
==28016==
==28016== For counts of detected and suppressed errors, rerun with: -v
==28016== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
edd@max:~/src/progs/C++$
#endif |
|
On OS X, I get the following errors using Dirk's stand-alone C++ code. (Armadillo version 6.400.3.) |
|
What's your LAPACK / BLAS library? I currently use Atlas: |
|
I linked to vecLib, Apple's version of BLAS/Lapack, in the Accelerate framework; compiler options: With OpenBLAS I get something similar: |
|
I never get |
|
Hmm. I just compiled the same file using gcc (v5) instead of clang: no specific (I suppressed the possibly lost part as this is a separate Valgrind-Mac issue, nothing to do with Armadillo.) |
|
Can't remember the version of gcc on my work computer, have to check it next year. I did manage to run the same RcppArmadillo case in old RHEL6.7 server which has gcc version 4.4.7 and R3.2.2 without any errors by valgrind. I also tested with clang3.5 on rocker/r-devel-ubsan-clang (din't rebuild it to latest R-devel though), and I got following: I guess these are nothing to worry about? |
|
The 'still reachable at end' is normal; R does not go around returning everything. I take comfort in the 'zero lost' leak summary. And that |
|
That said, I do of course have access to some clang variants on my Ubuntu box, and there is the whole Rocker suite so I can try to help you if you think you need another answer for CRAN. But as best as I can tell there is no real reproducible error here... |
|
Yes I agree that we can close this. I'll stick to |
|
Really appreciate that -- and at the same time we need to make sure that the less obvious and less often-used functions in (Rcpp)Armadillo get a fair shake and proper tests. Enjoy the break, and we will pick this next year. |
|
I just reinstalled BLAS, R etc, and I still got the same error, also by using the standalone C++ with newest Armadillo and OpenBLAS 2.14. I then updated gcc to 5.2.1 (from 4.8.5), and now the standalone C++ script runs without any errors. So yes it seems that this is a compiler error. |
|
Thanks a lot for the update, that is good to know. |
This was referenced May 4, 2016
|
It was actually a bug and has been solved in #91 |
|
Should we check / have you checked that is actually really fixed? |
|
Yes, I've checked, and the thing is that it works pre #91 and post #91, so it was not fixed with #91 since, as it was mentioned here, was not an issue of RcppArmadillo (sorry for the confusion!). On the other hand, I did experienced this issue with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am getting a valgrind error from
inv_sympd. I made a minimalistic package which can be used to reproduce the error at least in my RHEL7 using R version 3.2.2 ,RcppArmadillo_0.6.400.2.2, Rcpp_0.12.2 and valgrind-3.10.0. Here is the R part:And C++ part:
Here is the (long) output from valgrind:
The text was updated successfully, but these errors were encountered: