[Rcpp-devel] Logic error causes R memory to be corrupt

[Kevin Ushey]

I'm pretty sure I saw this post on StackOverflow before. Please don't cross
post, or at least indicate that you are when you do so. It's also nice to
give credit based on the advice you receive...

The main issue in your code, I think, is here:

struct Element : public std::enable_shared_from_this< Element > {
  SEXP key_;

  /* Simple constructor that assigns the key. */
  Element(SEXP key) : key_(key) {
    PROTECT(key_);
  }

  ~Element() {
    UNPROTECT_PTR(key_);
  }

  /* Convert the object to a R object. */
  operator SEXP() const;
};

Using PROTECT here is the wrong thing for SEXP class members -- PROTECT
uses the R stack-based protection scheme, and that will not work well for
objects whose lifetimes extend beyond the scope of when they're created.
You likely need `R_PreserveObject` and `R_ReleaseObject`. Note that this is
how Rcpp vectors ensure they are protected from the garbage collector.

Kevin

On Thu, Oct 6, 2016 at 9:31 AM, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> Hi Anton,
>
> Thanks for posting here.
>
> On 6 October 2016 at 10:52, Anton Bossenbroek wrote:
> | I want to add a large number of objects in C++ that are managed by
> `shared_ptr` in a `vector`. However, when I push the limits of the amount
> that I want to allocate the data in R becomes inconsistent.
>
> A bit of background.
>
> Rcpp exists because of the excellent idea (by Dominick, around 2004 to
> 2005)
> that using C++ templates for SEXP++ would make interfacing QuantLib easier
> in
> the RQuantLib package I had started a few years earlier.
>
> QuantLib is a marvel. It started in the early 2000s and was the first
> project
> I saw which has bet "big" on Boost testing, and, very importantly,
> shared_ptr.  QuantLib also makes extensive use of SWIG to govern interfaces
> to (a large number of) other languages.  And here is the key: None of those
> can use shared_ptr objects.  Neither does RQuantLib. Even though they are
> pervasive in QuantLib.
>
> Now, we are here to interface R.  All that Rcpp does, in essence, is making
> it trivially easy to get objects in and out of R as proxy objects:
> lightweight, no copy.  And the memory _is still managed by R_. So that you
> never need to use a SEXP directly in C++.  That is a feature.  [ Of course,
> sometimes you need the SEXP as a quasi-variant type, but that is not the
> common use. So let's just call it 'no SEXP in user code'. ]
>
> So I am not claiming that what you want to do here is impossible -- but I
> am
> not aware of another project having done this: hold R objects in a
> smart_ptr.
>
> Also, you haven't really explained what you want to do, what the life cyle
> of your
> objects is etc pp.
>
> At the simplest level, Rcpp use is synchronous:  you call from R, pass some
> content, do some calculations, report something back -- and everything
> intermediary is destroyed.  You can persist things, of course, when you
> manage the memory.  But you need to be very sure the things are then away
> from R -- copies are probably best. XPtr objects are used in that context.
>
> Anyway, end of short speech.  I would recommend you try to break you
> project
> into smaller, more fundamental tasks.  Maybe we can help with those, one
> by one.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> _______________________________________________
> 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/20161006/1b119d20/attachment.html>