Re: [Rcpp-devel] segfault on exit CRAN+Intel only
Hi Murray,
On 4 March 2024 at 07:03, Murray Efford wrote:
| Dirk
| Thanks for a very helpful reply. I'll simplify my return values.
|
| I mentioned Intel with rhub2 in my earlier post here, but I'm sorry
| that was somewhat buried. Debugging is somewhere between painful and
| impossible when my only check is submitting to CRAN!
It would be *really* helpful to have a path not involving CRAN.
| Also, I had tried valgrind, but that got stuck in Linux on what I
| assumed was an unrelated "unhandled instruction" error wrt OpenBLAS.
| That appeared unrelated, but maybe we need to factor it in as a
| possible interaction with RcppArmadillo. Strangely valgrind sticks on
| this --
| ==2242833== valgrind: Unrecognised instruction at address 0x57d3650.
| ==2242833==at 0x57D3650: dot_compute (in
| /opt/OpenBLAS/lib/libopenblas_skylakexp-r0.3.23.dev.so)
| -- even after I have set options(matprod="internal") in R, so
| something else (RcppArmadillo?) must be trying to use OpenBLAS.
That seems local to your system. I can just do 'R -d valgrind' as expected.
edd@rob:~$ R -q -d valgrind -e 'v <- integer(10)'
==2219911== Memcheck, a memory error detector
==2219911== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2219911== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2219911== Command: /usr/lib/R/bin/exec/R -q -e v~+~\<-~+~integer(10)
==2219911==
> v <- integer(10)
>
>
==2219911==
==2219911== HEAP SUMMARY:
==2219911== in use at exit: 51,025,490 bytes in 11,017 blocks
==2219911== total heap usage: 26,520 allocs, 15,503 frees, 78,392,784 bytes
allocated
==2219911==
==2219911== LEAK SUMMARY:
==2219911==definitely lost: 0 bytes in 0 blocks
==2219911==indirectly lost: 0 bytes in 0 blocks
==2219911== possibly lost: 0 bytes in 0 blocks
==2219911==still reachable: 51,025,490 bytes in 11,017 blocks
==2219911== of which reachable via heuristic:
==2219911== newarray : 4,264 bytes in 1 blocks
==2219911== suppressed: 0 bytes in 0 blocks
==2219911== Reachable blocks (those to which a pointer was found) are not shown.
==2219911== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2219911==
==2219911== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
edd@rob:~$
valgrind is pretty good and useful. I also enjoy the fact that eg tinytest
testfiles are script so we can test them in the aggregate, or in isolation,
or via their helper function.
edd@rob:~/git/rcpparmadillo/inst/tinytest(master)$ R -q -d valgrind -e
'tinytest::run_test_file("test_fastLm.R")'
==2243731== Memcheck, a memory error detector
==2243731== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2243731== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2243731== Command: /usr/lib/R/bin/exec/R -q -e
tinytest::run_test_file("test_fastLm.R")
==2243731==
> tinytest::run_test_file("test_fastLm.R")
test_fastLm.R. 30 tests OK 4.3s
All ok, 30 results (4.3s)
>
>
==2243731==
==2243731== HEAP SUMMARY:
==2243731== in use at exit: 58,200,576 bytes in 11,419 blocks
==2243731== total heap usage: 38,070 allocs, 26,651 frees, 141,466,157 bytes
allocated
==2243731==
==2243731== LEAK SUMMARY:
==2243731==definitely lost: 0 bytes in 0 blocks
==2243731==indirectly lost: 0 bytes in 0 blocks
==2243731== possibly lost: 0 bytes in 0 blocks
==2243731==still reachable: 58,200,576 bytes in 11,419 blocks
==2243731== of which reachable via heuristic:
==2243731== newarray : 4,264 bytes in 1 blocks
==2243731== suppressed: 0 bytes in 0 blocks
==2243731== Reachable blocks (those to which a pointer was found) are not shown.
==2243731== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2243731==
==2243731== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
edd@rob:~/git/rcpparmadillo/inst/tinytest(master)$
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
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
Re: [Rcpp-devel] segfault on exit CRAN+Intel only
Dirk Thanks for a very helpful reply. I'll simplify my return values. I mentioned Intel with rhub2 in my earlier post here, but I'm sorry that was somewhat buried. Debugging is somewhere between painful and impossible when my only check is submitting to CRAN! Also, I had tried valgrind, but that got stuck in Linux on what I assumed was an unrelated "unhandled instruction" error wrt OpenBLAS. That appeared unrelated, but maybe we need to factor it in as a possible interaction with RcppArmadillo. Strangely valgrind sticks on this -- ==2242833== valgrind: Unrecognised instruction at address 0x57d3650. ==2242833==at 0x57D3650: dot_compute (in /opt/OpenBLAS/lib/libopenblas_skylakexp-r0.3.23.dev.so) -- even after I have set options(matprod="internal") in R, so something else (RcppArmadillo?) must be trying to use OpenBLAS. Murray On Mon, Mar 4, 2024 at 1:58 AM Dirk Eddelbuettel wrote: > > > And "beauty" (ahem) of discussion scattered over two mailing lists: I now see > you have a testbed via rhub2 (good) even though it does not reproduce (hm...). > > So you could still try the suggested simplication. > > Cheers, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ 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
Re: [Rcpp-devel] segfault on exit CRAN+Intel only
And "beauty" (ahem) of discussion scattered over two mailing lists: I now see you have a testbed via rhub2 (good) even though it does not reproduce (hm...). So you could still try the suggested simplication. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ 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
Re: [Rcpp-devel] segfault on exit CRAN+Intel only
On 3 March 2024 at 20:47, Murray Efford wrote:
| A couple of days ago I posted on R-package-devel about a mysterious
| segfault from R CMD checks of my package secrdesign (see
| https://CRAN.R-project.org/package=secrdesign, and
| https://github.com/MurrayEfford/secrdesign) The issue rises only on
| CRAN and only with the Intel(R) oneAPI DPC++/C++ Compiler:
|
| *** caught segfault ***
| address (nil), cause 'unknown'
|
| As noted by Ivan Krylov and Uwe Ligges, the fault happens at the end
| of the R session (as it quits()). The package passes when checked on
| Intel(R) oneAPI DPC++/C++ Compiler 2023.2.0 (2023.2.0.20230721) with
| rhub2 .
|
| Now, CRAN via Uwe Ligges has accepted a new version of secrdesign
| despite the continuing error. My reason for raising it here is that
| (i) it is likely to raise its head next time I update,
| (ii) my experience may not be unique,
| (iii) my use of Rcpp, RcppArmadillo and BH in this package is very
| limited (https://github.com/MurrayEfford/secrdesign/tree/main/src),
| and it may therefore be provide clues to an Rcpp pro.
| (iv) I have just noticed a similar 'Additional issue' for
| https://CRAN.R-project.org/package=ipsecr that also uses Rcpp,
| RcppArmadillo and BH.
| Any advice would be welcome. I have no experience with docker, so
| answers in words of one or few syllables, please.
I was about to suggest to run with 'valgrind' and/or 'asan'/'ubsan' as many
folks do when chasing 'spurious' bugs related to memory -- but then CRAN
already does that for you and found nothing!
So it is hard to say anything. It could be a bug on your end, it could be a
bug in the compiler (!!), it could be a bug in the libraries. Now, Boost and
Armadillo are fairly mature and widely used so that is not likely either.
Given that you spotted another package in the same intersection it could be
an interaction.
But I am afraid you may need to work towards creating a 'workbench' where you
can chip away at this. Some of us can eyeball, and some are truly excellent
at this, but that may not be a reliable (or scalable) way forward.
[ goes looking ]
So I eyeballed your code. One thing I might do is keep the return object
simpler. Instead of (on-the fly) creation of Rcpp::List with Rcpp::Named that
contain scalars, maybe consider returning a Rcpp::NumericVector(2) and set
the two elements. You can still set 'names' on that too. A super-pedestrian
version is
> Rcpp::cppFunction('NumericVector myvec() { NumericVector v(2); v[0] = 1.23;
> v[1] = 2.34; CharacterVector nm(2); nm[0] = "foo"; nm[1] = "bar";
> v.attr("names") = nm; return v; }')
> myvec()
foo bar
1.23 2.34
>
and a fancier brace-initialization way is
> Rcpp::cppFunction('NumericVector myvec() { NumericVector v{1.23, 2.34};
> CharacterVector nm{"foo", "bar"}; v.attr("names") = nm; return v; }')
> myvec()
foo bar
1.23 2.34
>
Either works and avoids creation of temporaries at return which the (less
widely used !!) Intel compiler may resolve differently from g++ and clang++.
So it could be us, and defensive programming is always good but with repros
it so hard to say anything...
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
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
