El vie., 10 ago. 2018 a las 14:17, Tomas Kalibera
() escribió:
>
> Hi Iñaki,
>
> I think that "still reachable" memory is potentially a problem only if
> you cared about (frequent) package unloading, and if package unloading
> did not have correctness problems in the first place. I would only worry
Hi Iñaki,
I think that "still reachable" memory is potentially a problem only if
you cared about (frequent) package unloading, and if package unloading
did not have correctness problems in the first place. I would only worry
about "memory leaks" reported by valgrind.
That your example (unloa
Thanks, Tomas, Luke, for the clarifications. Then, I have another question.
But first, let me introduce how I ended up here, because obviously I
just don't go around dyn.unloading things that I've just compiled. I
was testing a package with valgrind. Everything ok, no leaks. Great.
But I'm always
On 9 August 2018 at 14:13, luke-tier...@uiowa.edu wrote:
| On Thu, 9 Aug 2018, Dirk Eddelbuettel wrote:
|
| >
| > On 9 August 2018 at 20:37, Tomas Kalibera wrote:
| > | So to answer your original question, this could probably be handled in
| > | Rcpp,
| >
| > Hm. Why do you say that / what did y
On Thu, 9 Aug 2018, Dirk Eddelbuettel wrote:
On 9 August 2018 at 20:37, Tomas Kalibera wrote:
| So to answer your original question, this could probably be handled in
| Rcpp,
Hm. Why do you say that / what did you have in mind?
We say it because it is true. Rcpp registers C finalizers and ru
On 9.8.2018 20:58, Dirk Eddelbuettel wrote:
On 9 August 2018 at 20:37, Tomas Kalibera wrote:
| So to answer your original question, this could probably be handled in
| Rcpp,
Hm. Why do you say that / what did you have in mind?
Recall that we do not alter SEXPs or introduce additional additio
On 9 August 2018 at 20:37, Tomas Kalibera wrote:
| So to answer your original question, this could probably be handled in
| Rcpp,
Hm. Why do you say that / what did you have in mind?
Recall that we do not alter SEXPs or introduce additional additional
reference counters -- because we do not th
R's dyn.unload() will unconditionally unload the given shared object; it
does not check whether there is any object (external pointer or weak
reference) with a C finalizer pointing into the space of the shared
object being unloaded. So it is expected that R will segfault later when
such fina
Hi all,
I'm not sure if I'm not supposed to do the following (the dyn.unload
part, I mean) or this could be a bug (in R or Rcpp):
```
Rcpp::sourceCpp(code='
#include
class Object {};
//[[Rcpp::export]]
SEXP new_object() {
return Rcpp::XPtr(new Object());
}'
)
new_object()
dyn.unlo
