[Rcpp-devel] Rcpp code in my package causes the R process to crash on fedora-clang

[Alexis Sarda]

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 <vmitov at 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 <
> 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 [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 | edd at debian.org
>
>
>
> --
> Venelin MITOV
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20200323/4b0f4a6e/attachment-0001.html>