[Rcpp-devel] Rcpp code in my package causes the R process to crash on fedora-clang
vmitov at gmail.com
Sun Mar 22 18:40:50 CET 2020
Thanks for your quick response, Dirk!
Concise and informative as usual.
Am So., 22. März 2020 um 17:57 Uhr schrieb Dirk Eddelbuettel <edd at debian.org>:
> On 22 March 2020 at 17:30, Venelin Mitov wrote:
> | 3. The line of code that is causing a segfault error and a crash of
> | the R-process is a call to the
> | std::logic_error() constructor. This line of code is found in the package's file
> | src/QuadraticPoly.h:
> | throw logic_error(oss.str());
> I always recommend to Rcpp::stop() which I use extensively and almost exclusively.
> | 4. However, throwing the above exception is correct - the
> | exception is intercepted (caught) at a higher functional level of the
> | PCMBaseCpp package, where it is handled. The same line of code is
> | executed without problem on all other flavours.
> | 5. Hence, my question is why std::logic_error(oss.str()) is
> | throwing a memory allocation exception on this specific CRAN flavour?
> I have no idea.
> But excception handling is genuinely complicated. Feel free to peruse the old
> issue ticket and pull request discussions at the Rcpp repo at GitHub -- there
> is lots of it.
> | I couldn't find anywhere in the R extension manual a text stating that
> | it is illegal to create std::logic_error objects in C++ code. The
> You missed that (at least parts of) R Core does not want us to use C++ in the
> first place -- or that is how one could read the (still somewhat
> "controversial" blog post ).
> | fact that the same code is passing on all other flavours including
> | rhub's fedora-clang suggests that this might be a local problem in the
> | fedora-clang test environment on CRAN.
> | Any advice on how I should proceed to prevent the package getting
> | removed from CRAN?
> Just because "it should work in theory" simply does not mean it will in
> practice. If a CRAN test machine consistently shows errors, I most often try
> to change my code . You could at least try that.
> A sad aspect in all this also is that we have no publically accessible
> machine behaving exactly like that Fedora box.
> | For you information, here is the stacktrace generated using gdb:
> No there wasn't.
> Standard GNU mailman mailing list setup so attachments are stripped.
>  http://developer.r-project.org/Blog/public/2019/03/28/use-of-c---in-packages/index.html
>  There are exceptions. I think the errors against anytime are a setup
> issue at their end as it genuinely happens nowhere else.
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
More information about the Rcpp-devel