SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Iñaki Úcar
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 <Rcpp.h>
  class Object {};
  //[[Rcpp::export]]
  SEXP new_object() {
    return Rcpp::XPtr<Object>(new Object());
  }'
)

new_object()
dyn.unload(list.files(tempdir(), ".(so|dll)$", recursive=TRUE, full.names=TRUE))
gc() # segfault in R_RunWeakRefFinalizer

message("This is not printed")
```

This is the backtrace I get with R 3.5.1:

#0  0x61ec4fd0 in ?? ()
#1  0x6ca1cafc in R_RunWeakRefFinalizer (w=0xc786a98) at memory.c:1393
#2  0x6ca1cdba in RunFinalizers () at memory.c:1459
#3  0x6ca1d024 in R_RunPendingFinalizers () at memory.c:1495
#4  R_gc () at memory.c:2893
#5  do_gc (call=0x1d45b88, op=0x15241d0, args=0x1d454b8,
rho=0x1d45318) at memory.c:2013
#6  0x6c9db60f in bcEval (body=body@entry=0x1d45a88,
rho=rho@entry=0x1d45318, useCache=useCache@entry=TRUE)
    at eval.c:6781
#7  0x6c9ecfb2 in Rf_eval (e=0x1d45a88, rho=0x1d45318) at eval.c:624
#8  0x6c9ee6f1 in R_execClosure (call=call@entry=0x0,
newrho=<optimized out>, sysparent=<optimized out>,
    rho=0x15a3370, arglist=0x18c2498, op=0x1d45968) at eval.c:1773
#9  0x6c9ef605 in Rf_applyClosure (call=0x15a3370,
call@entry=0x1d45828, op=0x18c2498, op@entry=0x1d45968,
    arglist=0x1d45968, rho=rho@entry=0x15a3370,
suppliedvars=0x18c2498) at eval.c:1701
#10 0x6c9ecf78 in Rf_eval (e=e@entry=0x1d45828,
rho=rho@entry=0x15a3370) at eval.c:747
#11 0x6ca11170 in Rf_ReplIteration (rho=0x15a3370, savestack=0,
browselevel=0, state=0x142edec) at main.c:258
#12 0x6ca11567 in R_ReplConsole (rho=<optimized out>, savestack=0,
browselevel=0) at main.c:308
#13 0x6ca11604 in run_Rmainloop () at main.c:1082
#14 0x6ca11700 in Rf_mainloop () at main.c:1089
#15 0x00401836 in AppMain (argc=1, argv=0x15c16f8) at rterm.c:86
#16 0x00401649 in WinMain@16 (Instance=0x400000, PrevInstance=0x0,
CmdLine=0x1904797 "", CmdShow=10)
    at graphappmain.c:23
#17 0x00402a8d in main ()

Any ideas?

Iñaki

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Tomas Kalibera

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 finalizer is run.

Currently there is no other way than to handle this on the side of the
shared library/package, e.g. as Luke does in his simplemmap package. A
library can declare R_unload_XXX function (see Writing R Extensions)
that will be called before it is unloaded. So, one can keep say a list
of objects with finalizers and clear/run the finalizers in R_unload_XXX.

I don't think we could do this automatically on the R's side with the
current API. I don't think there is a portable way to check if a given C
pointer is from a given loaded shared object (non-portable way on Linux
might be scanning the maps in the /proc filesystem). Also, doing this
for all objects with finalizers when unloading any library would
probably be slow. Adding some API to aid libraries in doing the
housekeeping is possible in principle.

So to answer your original question, this could probably be handled in
Rcpp, but in either case I would not use dyn.unload() in the first
place. This problem may be just one of many.

Best
Tomas



On 6.8.2018 17:35, Iñaki Úcar wrote:

> 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 <Rcpp.h>
>    class Object {};
>    //[[Rcpp::export]]
>    SEXP new_object() {
>      return Rcpp::XPtr<Object>(new Object());
>    }'
> )
>
> new_object()
> dyn.unload(list.files(tempdir(), ".(so|dll)$", recursive=TRUE, full.names=TRUE))
> gc() # segfault in R_RunWeakRefFinalizer
>
> message("This is not printed")
> ```
>
> This is the backtrace I get with R 3.5.1:
>
> #0  0x61ec4fd0 in ?? ()
> #1  0x6ca1cafc in R_RunWeakRefFinalizer (w=0xc786a98) at memory.c:1393
> #2  0x6ca1cdba in RunFinalizers () at memory.c:1459
> #3  0x6ca1d024 in R_RunPendingFinalizers () at memory.c:1495
> #4  R_gc () at memory.c:2893
> #5  do_gc (call=0x1d45b88, op=0x15241d0, args=0x1d454b8,
> rho=0x1d45318) at memory.c:2013
> #6  0x6c9db60f in bcEval (body=body@entry=0x1d45a88,
> rho=rho@entry=0x1d45318, useCache=useCache@entry=TRUE)
>      at eval.c:6781
> #7  0x6c9ecfb2 in Rf_eval (e=0x1d45a88, rho=0x1d45318) at eval.c:624
> #8  0x6c9ee6f1 in R_execClosure (call=call@entry=0x0,
> newrho=<optimized out>, sysparent=<optimized out>,
>      rho=0x15a3370, arglist=0x18c2498, op=0x1d45968) at eval.c:1773
> #9  0x6c9ef605 in Rf_applyClosure (call=0x15a3370,
> call@entry=0x1d45828, op=0x18c2498, op@entry=0x1d45968,
>      arglist=0x1d45968, rho=rho@entry=0x15a3370,
> suppliedvars=0x18c2498) at eval.c:1701
> #10 0x6c9ecf78 in Rf_eval (e=e@entry=0x1d45828,
> rho=rho@entry=0x15a3370) at eval.c:747
> #11 0x6ca11170 in Rf_ReplIteration (rho=0x15a3370, savestack=0,
> browselevel=0, state=0x142edec) at main.c:258
> #12 0x6ca11567 in R_ReplConsole (rho=<optimized out>, savestack=0,
> browselevel=0) at main.c:308
> #13 0x6ca11604 in run_Rmainloop () at main.c:1082
> #14 0x6ca11700 in Rf_mainloop () at main.c:1089
> #15 0x00401836 in AppMain (argc=1, argv=0x15c16f8) at rterm.c:86
> #16 0x00401649 in WinMain@16 (Instance=0x400000, PrevInstance=0x0,
> CmdLine=0x1904797 "", CmdShow=10)
>      at graphappmain.c:23
> #17 0x00402a8d in main ()
>
> Any ideas?
>
> Iñaki
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Dirk Eddelbuettel

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 think that altering the basic R API
for such calls would be a wise strategy.  So we do more or less what is done
in C for R, with some additional hand-holding which circumvents a number of
common errors.

| but in either case I would not use dyn.unload() in the first
| place. This problem may be just one of many.

I think I'd second that. I never had much unloading packages or dynamic
libraries and tend to "just say no". Both short-lived processes (ie via 'r')
as well as long sessions (ie R via ESS, running for weeks) work for my
workflows.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Tomas Kalibera


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 additional
> reference counters -- because we do not think that altering the basic R API
> for such calls would be a wise strategy.  So we do more or less what is done
> in C for R, with some additional hand-holding which circumvents a number of
> common errors.
Well if you wanted to support unloading - and I am not at all asking for
that - you could keep R objects (weak references, external pointers)
with C finalizers in some list and then unconditionally run or clear the
finalizers in your R_unload, something like Luke does in his example
package.

https://github.com/ltierney/Rpkg-simplemmap/blob/master/src/simplemmap.c

Best
Tomas

>
> | but in either case I would not use dyn.unload() in the first
> | place. This problem may be just one of many.
>
> I think I'd second that. I never had much unloading packages or dynamic
> libraries and tend to "just say no". Both short-lived processes (ie via 'r')
> as well as long sessions (ie R via ESS, running for weeks) work for my
> workflows.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Tierney, Luke
In reply to this post by Dirk Eddelbuettel
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 running
them after unloading will segfault. For now it would be better for Rcpp
(and everyone else) to explicitly discourage unloading as it is
unreliable on many levels.

What Rcpp could do to avoid segfaulting is to keep a weak list of all
objects to which it attaches C finalizers and arrange for those to be
cleaned up in an R_unload_<dllname> routine. Not clear it is worth the
trouble. At the R level we could provide more support for this since
we already have a weak list of objects with finalizers, but again not
clear it is worth the trouble.

Best,

luke

> Recall that we do not alter SEXPs or introduce additional additional
> reference counters -- because we do not think that altering the basic R API
> for such calls would be a wise strategy.  So we do more or less what is done
> in C for R, with some additional hand-holding which circumvents a number of
> common errors.
>
> | but in either case I would not use dyn.unload() in the first
> | place. This problem may be just one of many.
>
> I think I'd second that. I never had much unloading packages or dynamic
> libraries and tend to "just say no". Both short-lived processes (ie via 'r')
> as well as long sessions (ie R via ESS, running for weeks) work for my
> workflows.
>
> Dirk
>
>

--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   [hidden email]
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Dirk Eddelbuettel

On 9 August 2018 at 14:13, [hidden email] 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 you have in mind?
|
| We say it because it is true. Rcpp registers C finalizers and running
| them after unloading will segfault. For now it would be better for Rcpp
| (and everyone else) to explicitly discourage unloading as it is
| unreliable on many levels.
|
| What Rcpp could do to avoid segfaulting is to keep a weak list of all
| objects to which it attaches C finalizers and arrange for those to be
| cleaned up in an R_unload_<dllname> routine. Not clear it is worth the
| trouble. At the R level we could provide more support for this since
| we already have a weak list of objects with finalizers, but again not
| clear it is worth the trouble.

Ah, noted, thanks for the explainer.

As I remain in camp "don't try unloading" I won't make this a priority
myself, but as always open to credible PRs. Could start with an issue ticket
and discussion if anybody is so inclined.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Iñaki Úcar
In reply to this post by Tierney, Luke
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 suspicious (probably unjustifiably) of all the memory
that is reported as "still reachable", so I wanted to check whether
there was any difference if I detach(unload=TRUE) the package after
all the tests.

In a nutshell, I ended up discovering that the following code:

```
library(simmer)
simmer() # allocates a C++ object, as in my initial example
detach("package:simmer", unload=TRUE)
```

segfaults on Windows, but not on Linux (then I built the example in my
initial email to confirm it wasn't simmer's fault). So given that,
from your explanation, I should expect a segfault here, the question
is: what on Earth does (or does not) R on Linux do to avoid
segfaulting compared to Windows? :) And a corolary would be, can't R
on Windows do the same?

Regards,
Iñaki

El jue., 9 ago. 2018 a las 21:13, <[hidden email]> escribió:

>
> 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 running
> them after unloading will segfault. For now it would be better for Rcpp
> (and everyone else) to explicitly discourage unloading as it is
> unreliable on many levels.
>
> What Rcpp could do to avoid segfaulting is to keep a weak list of all
> objects to which it attaches C finalizers and arrange for those to be
> cleaned up in an R_unload_<dllname> routine. Not clear it is worth the
> trouble. At the R level we could provide more support for this since
> we already have a weak list of objects with finalizers, but again not
> clear it is worth the trouble.
>
> Best,
>
> luke
>
> > Recall that we do not alter SEXPs or introduce additional additional
> > reference counters -- because we do not think that altering the basic R API
> > for such calls would be a wise strategy.  So we do more or less what is done
> > in C for R, with some additional hand-holding which circumvents a number of
> > common errors.
> >
> > | but in either case I would not use dyn.unload() in the first
> > | place. This problem may be just one of many.
> >
> > I think I'd second that. I never had much unloading packages or dynamic
> > libraries and tend to "just say no". Both short-lived processes (ie via 'r')
> > as well as long sessions (ie R via ESS, running for weeks) work for my
> > workflows.
> >
> > Dirk
> >
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa                  Phone:             319-335-3386
> Department of Statistics and        Fax:               319-335-3017
>     Actuarial Science
> 241 Schaeffer Hall                  email:   [hidden email]
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



--
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Tomas Kalibera
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 (unloading a library while there is still an object
with a finalizer implemented in that library) segfaults on one system
but not another is not too surprising. Depending on the OS, the dynamic
linker, the current state of the system, etc - when the GC tries to run
the finalizer, it may point to inaccessible memory (segfault), but also
still to the code of the unloaded finalizer (possibly no segfault) or
something else. There is no way to distinguish between all these cases
before running the finalizer - neither the OS nor R can do it - we could
only in principle, with a lot of other problems and platform-dependent
hacks, detect when the memory is inaccessible, but that may not be worth it.

Best
Tomas


On 08/10/2018 12:46 AM, Iñaki Úcar wrote:

> 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 suspicious (probably unjustifiably) of all the memory
> that is reported as "still reachable", so I wanted to check whether
> there was any difference if I detach(unload=TRUE) the package after
> all the tests.
>
> In a nutshell, I ended up discovering that the following code:
>
> ```
> library(simmer)
> simmer() # allocates a C++ object, as in my initial example
> detach("package:simmer", unload=TRUE)
> ```
>
> segfaults on Windows, but not on Linux (then I built the example in my
> initial email to confirm it wasn't simmer's fault). So given that,
> from your explanation, I should expect a segfault here, the question
> is: what on Earth does (or does not) R on Linux do to avoid
> segfaulting compared to Windows? :) And a corolary would be, can't R
> on Windows do the same?
>
> Regards,
> Iñaki
>
> El jue., 9 ago. 2018 a las 21:13, <[hidden email]> escribió:
>> 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 running
>> them after unloading will segfault. For now it would be better for Rcpp
>> (and everyone else) to explicitly discourage unloading as it is
>> unreliable on many levels.
>>
>> What Rcpp could do to avoid segfaulting is to keep a weak list of all
>> objects to which it attaches C finalizers and arrange for those to be
>> cleaned up in an R_unload_<dllname> routine. Not clear it is worth the
>> trouble. At the R level we could provide more support for this since
>> we already have a weak list of objects with finalizers, but again not
>> clear it is worth the trouble.
>>
>> Best,
>>
>> luke
>>
>>> Recall that we do not alter SEXPs or introduce additional additional
>>> reference counters -- because we do not think that altering the basic R API
>>> for such calls would be a wise strategy.  So we do more or less what is done
>>> in C for R, with some additional hand-holding which circumvents a number of
>>> common errors.
>>>
>>> | but in either case I would not use dyn.unload() in the first
>>> | place. This problem may be just one of many.
>>>
>>> I think I'd second that. I never had much unloading packages or dynamic
>>> libraries and tend to "just say no". Both short-lived processes (ie via 'r')
>>> as well as long sessions (ie R via ESS, running for weeks) work for my
>>> workflows.
>>>
>>> Dirk
>>>
>>>
>> --
>> Luke Tierney
>> Ralph E. Wareham Professor of Mathematical Sciences
>> University of Iowa                  Phone:             319-335-3386
>> Department of Statistics and        Fax:               319-335-3017
>>      Actuarial Science
>> 241 Schaeffer Hall                  email:   [hidden email]
>> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
>
>
> --
> Iñaki Úcar
> http://www.enchufa2.es
> @Enchufa2

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp

Iñaki Úcar
El vie., 10 ago. 2018 a las 14:17, Tomas Kalibera
(<[hidden email]>) 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
> about "memory leaks" reported by valgrind.
>
> That your example (unloading a library while there is still an object
> with a finalizer implemented in that library) segfaults on one system
> but not another is not too surprising. Depending on the OS, the dynamic
> linker, the current state of the system, etc - when the GC tries to run
> the finalizer, it may point to inaccessible memory (segfault), but also
> still to the code of the unloaded finalizer (possibly no segfault) or
> something else. There is no way to distinguish between all these cases
> before running the finalizer - neither the OS nor R can do it - we could
> only in principle, with a lot of other problems and platform-dependent
> hacks, detect when the memory is inaccessible, but that may not be worth it.

Ok, I get it. And I agree: it's not worth it. Thanks again.

Iñaki

>
> Best
> Tomas
>
>
> On 08/10/2018 12:46 AM, Iñaki Úcar wrote:
> > 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 suspicious (probably unjustifiably) of all the memory
> > that is reported as "still reachable", so I wanted to check whether
> > there was any difference if I detach(unload=TRUE) the package after
> > all the tests.
> >
> > In a nutshell, I ended up discovering that the following code:
> >
> > ```
> > library(simmer)
> > simmer() # allocates a C++ object, as in my initial example
> > detach("package:simmer", unload=TRUE)
> > ```
> >
> > segfaults on Windows, but not on Linux (then I built the example in my
> > initial email to confirm it wasn't simmer's fault). So given that,
> > from your explanation, I should expect a segfault here, the question
> > is: what on Earth does (or does not) R on Linux do to avoid
> > segfaulting compared to Windows? :) And a corolary would be, can't R
> > on Windows do the same?
> >
> > Regards,
> > Iñaki
> >
> > El jue., 9 ago. 2018 a las 21:13, <[hidden email]> escribió:
> >> 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 running
> >> them after unloading will segfault. For now it would be better for Rcpp
> >> (and everyone else) to explicitly discourage unloading as it is
> >> unreliable on many levels.
> >>
> >> What Rcpp could do to avoid segfaulting is to keep a weak list of all
> >> objects to which it attaches C finalizers and arrange for those to be
> >> cleaned up in an R_unload_<dllname> routine. Not clear it is worth the
> >> trouble. At the R level we could provide more support for this since
> >> we already have a weak list of objects with finalizers, but again not
> >> clear it is worth the trouble.
> >>
> >> Best,
> >>
> >> luke
> >>
> >>> Recall that we do not alter SEXPs or introduce additional additional
> >>> reference counters -- because we do not think that altering the basic R API
> >>> for such calls would be a wise strategy.  So we do more or less what is done
> >>> in C for R, with some additional hand-holding which circumvents a number of
> >>> common errors.
> >>>
> >>> | but in either case I would not use dyn.unload() in the first
> >>> | place. This problem may be just one of many.
> >>>
> >>> I think I'd second that. I never had much unloading packages or dynamic
> >>> libraries and tend to "just say no". Both short-lived processes (ie via 'r')
> >>> as well as long sessions (ie R via ESS, running for weeks) work for my
> >>> workflows.
> >>>
> >>> Dirk
> >>>
> >>>
> >> --
> >> Luke Tierney
> >> Ralph E. Wareham Professor of Mathematical Sciences
> >> University of Iowa                  Phone:             319-335-3386
> >> Department of Statistics and        Fax:               319-335-3017
> >>      Actuarial Science
> >> 241 Schaeffer Hall                  email:   [hidden email]
> >> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel