malloc: *** error for object 0x7fffb262e9f0: pointer being freed was not allocated

[spennihana]

I've encountered this issue upon exit of an RInside program. The issue is resolved with the top-of-tree branch of RInside, and I am wondering if this update (0.2.14 -> 0.2.14.1) will make it to CRAN sometime soon.

Thanks!

My sessionInfo and steps to reproduce are below.

> sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.5

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_3.4.3

steps:

1. compile and run any of the example RInside programs from inst/examples/standard

[eddelbuettel]

Hm. Code has not really changed, nor have the examples. CRAN shows no issues either. Moreover, the two small changes since 0.2.14 are minimal. Are you sure the issue is not just fixed by a standard recompilation? Sometimes you need to reinstall the same version when your compiler changes...

[spennihana]

I see, my compiler != CRAN compiler.
I re-installed the RInside from CRAN via install.packages("RInside", type="source") and no longer have the issue. I suppose CRAN does not periodically update the binaries when it reruns its checks then!

IIUC, this is not an issue, then, if a package depending on RInside is distributed via CRAN; but may be commonly an issue in development environments since the binary on CRAN does not update often.

Actually, will this be a problem for packages distributed via CRAN if that binary does not get udpated?

[eddelbuettel]

Thanks for reporting back -- and yes, this can happen. For Windows, CRAN does complete rebuilds when needed. For macOS not quite the same resources so going to source in times of trouble can be the difference.

I'll close this.

[spennihana]

OK, thanks for your help :)