Skip to content

[R-pkg-devel] can't reproduce cran-pretest error

5 messages · Iñaki Ucar, John C Nash, Göran Broström +1 more

#
Dear list,

I'm having trouble reproducing errors from CRAN's pretests.

I have a package on CRAN called epanet2toolkit that provides R bindings
to a legacy simulation engine written in C.  So far I've released two
versions
to CRAN without trouble.  Now I'm making a third release, principally to
include
a citation for the package, but also to clean up warnings raised by new
compilers.

My latest submission fails the CRAN pretests for Debian with errors in the
examples and tests:
https://win-builder.r-project.org/incoming_pretest/
epanet2toolkit_0.3.0_20180726_102947/Debian/00check.log

For what it's worth, the package checks fine under R-3.4.4, R-3.5.0 and
R-devel
r74997 (2018-07-21) and r74923 (2018-06-20).

However, when I run the debian-r-devel checks locally (albeit in Docker) I
get
a couple of warnings, but no errors. Since I can't reproduce the error, it's
difficult to fix. See below the relevant lines of 00check.log:

* using log directory ?/pkg/epanet2toolkit.Rcheck?
* using R Under development (unstable) (2018-07-25 r75006)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* using option ?--as-cran?
* checking for file ?epanet2toolkit/DESCRIPTION? ... OK
* checking extension type ... Package
...
* checking whether package ?epanet2toolkit? can be installed ... WARNING
Found the following significant warnings:
  text.h:421:9: warning: ?        Kw        Kw      /d? directive writing
30 bytes into a region of size between 23 and 278 [-Wformat-overflow=]
See ?/pkg/epanet2toolkit.Rcheck/00install.out? for details.
...
* checking compilation flags used ... WARNING
Compilation used the following non-portable flag(s):
  ?-Wdate-time? ?-Werror=format-security? ?-Wformat?
* checking compiled code ... OK
* checking examples ... OK
* checking for unstated dependencies in ?tests? ... OK
* checking tests ... OK
  Running ?testthat.r?
* checking PDF version of manual ... OK
* DONE
Status: 2 WARNINGs, 1 NOTE


Thanks in advance for any insights.
#
Hi, a couple of things,:

1) Have you checked the rchk report for possible issues?

https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/epanet2toolkit.out

2) Here there's a call to RENgettimeparam, which passes an empty
character buffer:

https://github.com/bradleyjeck/epanet2toolkit/blob/1e88c805ca294f980fc9133851eb5be8239086b5/R/times.r#L74

but then this function applies a sprintf over this empty buffer (!), here:

https://github.com/bradleyjeck/epanet2toolkit/blob/ef66748de5b357bfe6bbad4b3ba7e5f271baa797/src/Repanet2.c#L81

This more or less matches the error shown in the pre-test, i.e.:

"array over-run in .C("RENgettimeparam") in character argument 2, element 1"

Regards,
I?aki


El jue., 26 jul. 2018 a las 21:20, Brad Eck (<bradleyjeck at gmail.com>) escribi?:
#
I think several of us have had similar issues lately. You might have seen my posts on reverse dependencies.
It seems there are some sensitivities in the CRAN test setup, though I think things are improving.

Last week I submitted optimx again. I don't think I changed anything but the date and some commentary
in documentation files. The pre-test was much better than before, but still had two "complaints". One of
these was an "ERROR" of the type "non-convergence -- please choose a different minimizer" (in mvord)
and the other was a "WARNING" since my new package (optimx) subsumes the functionality of several other
packages, including optextras, so the functions from that were now masked, as might be expected. This
was in surrosurv.

However, I did follow protocol and report these false positives, but have had no response from CRAN
team. Nor any response to previous msgs about 2 months ago. I suspect some volunteer overload, but
if that is the case, I would hope the CRAN team would ask for help. I know there are several of us
willing to help if we can. And the new functionality does fix some actual bugs, as well as providing
improvements. Without renewal, particularly for infrastructure packages, R will decay.

Cheers, JN
On 2018-07-26 03:11 PM, Brad Eck wrote:
#
Inline:
On 2018-07-26 21:11, Brad Eck wrote:
This warning can safely be ignored, I have been told. It may also be 
avoided:

https://stat.ethz.ch/pipermail/r-package-devel/2018q3/002878.html

G?ran
#
Thanks to  I?aki for the correct diagnosis.

He also pointed out that setting the environment variable
R_C_BOUNDS_CHECK=yes as described in ?options would reproduce the error.
It seems this environment variable is set on CRAN's pre-test environment,
but not on any of the other environments I was testing on.
On Thu, Jul 26, 2018 at 8:49 PM, I?aki ?car <i.ucar86 at gmail.com> wrote: