[Rcpp-devel] Rcpp example that crashes on 64 bit Windows

On 11 August 2016 at 06:28, Rajen Shah wrote:
| Hello,
|
| I am having trouble debugging a package that appears to work fine on Mac
| operating systems but crashes on Unix and Windows.
|
| I have found the following example that crashes on my Windows setup
(session
| info copied below)
|
| IntegerVector runif_int2() {
|   return wrap(floor(runif(1000000)));
| }
|
| When this is called about 5-10 times in succession R crashes (e.g. with
| set.seed(1), but this doesn't seem to matter).
|
| Any ideas about why this crashes would be much appreciated. To be clear,
I am
| not looking for an alternative to the above code (which simply produces a
| vector of zeroes), but would like to know what aspects of this cause a
crash so
| I know what code structures may be causing problems in the package I am
| creating. The code does not appear to crash on Mac and I have yet to try
it on
| Unix.

i)  On my box it doesn't run (which is probably a bug)

R> library(Rcpp)
R> cppFunction("IntegerVector runif_int2() { return
wrap(floor(runif(1000000))); }")
R> set.seed(1)
R> replicate(100, runif_int2())   ## should probably use loop here...
Error in runif_int2() : unimplemented type 'integer' in 'coerceToInteger'
R>

ii) Your code is still "wrong" or less than ideal. You really are working
with doubles there, even after the floor() around runif.  So maybe return a
double vector?  Else assign explictly via a cast.

Dirk




|
| Many thanks in advance,
|
| Rajen
|
| Session info:
|
| R version 3.3.1 (2016-06-21)
| Platform: x86_64-w64-mingw32/x64 (64-bit)
| Running under: Windows >= 8 x64 (build 9200)
|
| locale:
| [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
States.1252
|    LC_MONETARY=English_United States.1252
| [4] LC_NUMERIC=C                           LC_TIME=English_United
States.1252
|
|
| attached base packages:
| [1] stats     graphics  grDevices utils     datasets  methods   base
|
| loaded via a namespace (and not attached):
| [1] tools_3.3.1
| _______________________________________________
| 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

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

library(Rcpp)
cppFunction("IntegerVector runif_int2() { return

set.seed(1)
gctorture(TRUE)
z <- runif_int2()
z <- runif_int2()

Hello,

I am having trouble debugging a package that appears to work fine on Mac
operating systems but crashes on Unix and Windows.

I have found the following example that crashes on my Windows setup
(session info copied below)

IntegerVector runif_int2() {
  return wrap(floor(runif(1000000)));
}

When this is called about 5-10 times in succession R crashes (e.g. with
set.seed(1), but this doesn't seem to matter).

Any ideas about why this crashes would be much appreciated. To be clear, I
am not looking for an alternative to the above code (which simply produces
a vector of zeroes), but would like to know what aspects of this cause a
crash so I know what code structures may be causing problems in the package
I am creating. The code does not appear to crash on Mac and I have yet to
try it on Unix.

Many thanks in advance,

Rajen

Session info:

R version 3.3.1 (2016-06-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United
States.1252    LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C                           LC_TIME=English_United
States.1252

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

loaded via a namespace (and not attached):
[1] tools_3.3.1

To follow-up, if we avoid the cast this works just find as you'd expect:

R> cppFunction("NumericVector myrunif() { return floor(runif(1000000)); }")
R> for (i in 1:100) ignoreme <- myrunif()
R>

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Many thanks Bill and Dirk.

I'm now explicitly casting each element and this works fine. I was just
surprised that this inappropriate use of wrap would cause a memory leak on
certain OS's and run without problems on others.

Best wishes,

Rajen

On 11 August 2016 at 10:18, Dirk Eddelbuettel <edd at debian.org> wrote:

To follow-up, if we avoid the cast this works just find as you'd expect:

R> cppFunction("NumericVector myrunif() { return floor(runif(1000000));
}")
R> for (i in 1:100) ignoreme <- myrunif()
R>

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Have you tried running your code on the Mac after setting gctorture(TRUE)?

By the way, valgrind showed the opposite of a memory leak - the code was

Have you tried running your code on the Mac after setting gctorture(TRUE)?

By the way, valgrind showed the opposite of a memory leak - the code was
using memory that it had declared free.  A leak is when the code does not
free memory that it can no longer use.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Aug 11, 2016 at 8:28 AM, Rajen Shah <rds37 at cam.ac.uk> wrote:

Many thanks Bill and Dirk.

I'm now explicitly casting each element and this works fine. I was just
surprised that this inappropriate use of wrap would cause a memory leak on
certain OS's and run without problems on others.

Best wishes,

Rajen

On 11 August 2016 at 10:18, Dirk Eddelbuettel <edd at debian.org> wrote:

To follow-up, if we avoid the cast this works just find as you'd expect:

R> cppFunction("NumericVector myrunif() { return floor(runif(1000000));
}")
R> for (i in 1:100) ignoreme <- myrunif()
R>

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Have you tried running your code on the Mac after setting

gctorture(TRUE)?

No I have not tried this (and no longer have the Mac available
unfortunately). I have a very limited understanding of memory management,
but I guess you're suggesting setting this to TRUE would make sure that
freed memory really is free, and so would help uncover an issue where the
code tries to use memory that it has declared free?

By the way, valgrind showed the opposite of a memory leak - the code

was using memory that it had declared free.  A leak is when the code does
not free memory that it can no longer use.

I am unfamiliar with how to interpret valgrid output, but are you deducing
this from "allocs > frees"?

Thanks: a useful way of finding the most horrible memory issue bugs it
seems.

Rajen

On 11 August 2016 at 10:33, William Dunlap <wdunlap at tibco.com> wrote:

Have you tried running your code on the Mac after setting gctorture(TRUE)?

By the way, valgrind showed the opposite of a memory leak - the code was
using memory that it had declared free.  A leak is when the code does not
free memory that it can no longer use.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Aug 11, 2016 at 8:28 AM, Rajen Shah <rds37 at cam.ac.uk> wrote:

Many thanks Bill and Dirk.

I'm now explicitly casting each element and this works fine. I was just
surprised that this inappropriate use of wrap would cause a memory leak on
certain OS's and run without problems on others.

Best wishes,

Rajen

On 11 August 2016 at 10:18, Dirk Eddelbuettel <edd at debian.org> wrote:

To follow-up, if we avoid the cast this works just find as you'd expect:

R> cppFunction("NumericVector myrunif() { return floor(runif(1000000));
}")
R> for (i in 1:100) ignoreme <- myrunif()
R>

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org