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

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

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