search for: releaselargefreevectors

...ntation fault. 0x40111109 in chunk_free (ar_ptr=0x401a5d40, p=0x94723a8) at malloc.c:3111 3111 malloc.c: No such file or directory. (gdb) bt #0 0x40111109 in chunk_free (ar_ptr=0x401a5d40, p=0x94723a8) at malloc.c:3111 #1 0x40110f9a in __libc_free (mem=0x94727d0) at malloc.c:3023 #2 0x80a6b60 in ReleaseLargeFreeVectors () at memory.c:673 #3 0x80a82b2 in RunGenCollect (size_needed=2000) at memory.c:1079 #4 0x80a9365 in R_gc_internal (size_needed=2000) at memory.c:1669 #5 0x80a9027 in Rf_allocVector (type=14, length=2000) at memory.c:1541 #6 0x808cb58 in Rf_duplicate (s=0x9548498) at duplicate.c:140 #7 0x80660...

...0x4FA7570: R_ReplConsole (main.c:308) ==4711== by 0x4FA760E: run_Rmainloop (main.c:1082) ==4711== by 0x40075A: main (Rmain.c:29) ==4711== Address 0x19b3ab90 is 0 bytes inside a block of size 160,048 free'd ==4711== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==4711== by 0x4FAFCB2: ReleaseLargeFreeVectors (memory.c:1055) ==4711== by 0x4FAFCB2: RunGenCollect (memory.c:1825) ==4711== by 0x4FAFCB2: R_gc_internal (memory.c:2998) ==4711== by 0x4FB166F: Rf_allocVector3 (memory.c:2682) ==4711== by 0x4FB2310: Rf_allocVector (Rinlinedfuns.h:577) ==4711== by 0x4FB2310: R_alloc (memory.c:2197) =...

...x80CB5E0: Rf_applyClosure (eval.c:614) ==11423== by 0x80CB1B7: Rf_eval (eval.c:455) ==11423== by 0x80CCAC1: do_begin (eval.c:1107) ==11423== Address 0x473D163 is 3 bytes inside a block of size 168 free'd ==11423== at 0x401B2A3: free (vg_replace_malloc.c:233) ==11423== by 0x80ED27C: ReleaseLargeFreeVectors (memory.c:759) ==11423== by 0x80EED30: RunGenCollect (memory.c:1351) ==11423== by 0x80F0635: R_gc_internal (memory.c:2141) ==11423== by 0x80F000C: Rf_allocVector (memory.c:1942) ==11423== by 0x814F67A: RestoreToEnv (saveload.c:2038) ==11423== by 0x8150465: do_loadFromConn2 (saveload....

....c:308) > ==4711== by 0x4FA760E: run_Rmainloop (main.c:1082) > ==4711== by 0x40075A: main (Rmain.c:29) > ==4711== Address 0x19b3ab90 is 0 bytes inside a block of size 160,048 > free'd > ==4711== at 0x4C2ACBD: free (vg_replace_malloc.c:530) > ==4711== by 0x4FAFCB2: ReleaseLargeFreeVectors (memory.c:1055) > ==4711== by 0x4FAFCB2: RunGenCollect (memory.c:1825) > ==4711== by 0x4FAFCB2: R_gc_internal (memory.c:2998) > ==4711== by 0x4FB166F: Rf_allocVector3 (memory.c:2682) > ==4711== by 0x4FB2310: Rf_allocVector (Rinlinedfuns.h:577) > ==4711== by 0x4FB2310:...

The following code crashes after about 300 iterations on my?x86_64-w64-mingw32?machine on R 3.5.2 --vanilla.?? Others have duplicated this (see?https://github.com/tidyverse/magrittr/issues/190?if necessary), but I don't know how machine/OS-dependent it may be.?? If it doesn't crash for you, please try increasing the length of the x vector. Substituting the commented-out line for the one

...by 0x4EF9F91: Rf_applyClosure (eval.c:666) ==25398== by 0x4EF988D: Rf_eval (eval.c:507) ==25398== Address 0x8F46010 is 72,976 bytes inside a block of size 182,760 free'd ==25398== at 0x4C226DB: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==25398== by 0x4F2D848: ReleaseLargeFreeVectors (memory.c:760) ==25398== by 0x4F359E9: RunGenCollect (memory.c:1378) ==25398== by 0x4F38938: R_gc_internal (memory.c:2171) ==25398== by 0x4F38046: Rf_allocVector (memory.c:1961) ==25398== by 0x4EDE779: duplicate1 (duplicate.c:221) ==25398== by 0x4EDD698: Rf_duplicate (duplicate.c:115...

...1.2.0 is uncovering bad code in the *.so, but could there be an interaction between dynamic memory management in R >= 1.2 and C++ (g++)? (namespace???). It strikes me as odd that the SIGSEGV sometimes comes from the C++ side (annDeallocPts - __builtin_vec_delete), and sometimes from the R side (ReleaseLargeFreeVectors), with no pattern that I can see. Roger -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Breiviksveien 40, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93 e-mail: Roger.Bivand@nhh.no and: Department...

I believe there is a memory leak in isoreg in the current version of R, as I believe the following shows > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 120405 3.3 350000 9.4 350000 9.4 Vcells 78639 0.6 786432 6.0 392463 3.0 > for(k in 1:100) { + + y <- runif(10000) + isoreg(x,y) + } > rm(x) > rm(y) > gc() used (Mb) gc

I have a data set of roughly 700MB which during processing grows up to 2G ( I'm using a 4G linux box). After the work is done I clean up (rm()) and the state is returned to 700MB. Yet I find I cannot run the same routine again as it claims to not be able to allocate memory even though gcinfo() claims there is 1.1G left. At the start of the second time ===============================

I have a data set of roughly 700MB which during processing grows up to 2G ( I'm using a 4G linux box). After the work is done I clean up (rm()) and the state is returned to 700MB. Yet I find I cannot run the same routine again as it claims to not be able to allocate memory even though gcinfo() claims there is 1.1G left. At the start of the second time ===============================

If anyone has a few extra CPU cycles to spare, I'd appreciate it if you could verify a problem that I have encountered. Run the code below and tell me if it crashes your R before completion. library(lme4) data(bdf) dump<-sapply( 1:50000, function(i) { fm <- lme(langPOST ~ IQ.ver.cen + avg.IQ.ver.cen, data = bdf, random = ~ IQ.ver.cen | schoolNR); cat("