Displaying 9 results from an estimated 9 matches for "r_runweakreffin".
2018 Aug 09
0
SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
...t; 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 0x6ca...
2018 Aug 06
2
SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
...cpp::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:...
2018 Aug 09
0
SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
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
2018 Aug 10
0
SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
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
2018 Aug 09
4
SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
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
2018 Aug 09
2
SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
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
2008 Aug 28
1
locale2charset CPU overhead (PR#12633)
...L) (83.25.29.163)
Hello!
I have conducted following experiment running simple R script:
for (i in 1:10000) {
a<-0
for (j in 1:1000)
a<-c(a,j)
}
profiled R.dll using Intel Vtune and obtained following results!!!
Func. Name Clocticks
locale2charset 46,58%
R_RunWeakRefFinalizer 20,85%
Rf_eval 8,77%
Rf_eval takes only about 9% of CPU time, a huge overhead on checking
locale character set!!! It seems that is the problem with family of
functions: c(), rbind(), cbind()
2010 Mar 06
2
memory error in for loop
.../i686/cmov/libc.so.6[0xb7486824]
/lib/i686/cmov/libc.so.6[0xb74880b3]
/lib/i686/cmov/libc.so.6(cfree+0x6d)[0xb748b0dd]
/usr/lib/libpq.so.5(PQclear+0xf6)[0xb6e53976]
/home/ptittmann/R/i486-pc-linux-gnu-library/2.10/RdbiPgSQL/libs/RdbiPgSQL.so(PgSQLclearResult+0x25)[0xb6fc2665]
/usr/lib/R/lib/libR.so(R_RunWeakRefFinalizer+0x161)[0xb76721f1]
/usr/lib/R/lib/libR.so[0xb7672357]
/usr/lib/R/lib/libR.so[0xb76743fe]
/usr/lib/R/lib/libR.so(Rf_allocVector+0xb8)[0xb7675628]
/usr/lib/R/lib/libR.so(Rf_usemethod+0x41d)[0xb768306d]
2008 Jul 14
0
RODBC Seg Fault
...ory.c:2445
2445 memory.c: No such file or directory.
in memory.c
(gdb) bt
#0 0x08059036 in R_ClearExternalPtr (s=0x0) at memory.c:2445
#1 0x006b17cb in inRODBCClose (thisHandle=0x8c1f358) at RODBC.c:1250
#2 0x006b190d in chanFinalizer (ptr=0x9100380) at RODBC.c:1271
#3 0x0805b6eb in R_RunWeakRefFinalizer (w=0x90da4f8) at memory.c:1062
#4 0x0805b810 in RunFinalizers () at memory.c:1107
#5 0x0805cf17 in R_gc_internal (size_needed=1) at memory.c:2205
#6 0x0805da69 in Rf_allocVector (type=16, length=1) at memory.c:1968
#7 0x006b3955 in RODBCDriverConnect (connection=0x90b0208, id=0x90b0288,...