FWIW, I have the same problem, which is what I reported here: https://github.com/RcppCore/Rcpp/issues/972#issuecomment-593291723
I haven't been able to solve it because I can't reproduce it (I don't have a Mac, and the Docker container with that R setup doesn't fail). In my case, it could be that the exception pointer ends up being null, like in this unrelated issue I found: https://github.com/dart-lang/sdk/issues/38141 But until I get access to a Mac, I won't be sure. Regards, Alexis. On Sun, Mar 22, 2020, 18:41 Venelin Mitov <vmi...@gmail.com> wrote: > Thanks for your quick response, Dirk! > > Concise and informative as usual. > > Best, > Venelin > > Am So., 22. März 2020 um 17:57 Uhr schrieb Dirk Eddelbuettel < > e...@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 [1]). > > > > | 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 [2]. 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. > > > > Dirk > > > > [1] > http://developer.r-project.org/Blog/public/2019/03/28/use-of-c---in-packages/index.html > > [2] 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 | e...@debian.org > > > > -- > Venelin MITOV > _______________________________________________ > 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
_______________________________________________ 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
