search for: do_dotcall

I've stumbled upon a small bug/inconsitency in do_External and do_dotcall: Here's an example: % LC_ALL=C R --vanilla < symname-bug.R R version 2.8.0 (2008-10-20) *snip* > options(error=expression(0)) > ## Call 'R_GD_nullDevice' with incorrect parameter count: > .Call("R_GD_nullDevice", 1) Error in .Call("R_GD_n...

...course I don't understand what's going on here and so don't trust it. The list SEXP I am returning was allocated by R, not by my C code, so why does it make any difference whether my C function returns it or not? >From "src/main/names.c" I see that .Call is implemented by do_dotcall in "src/main/dotcode.c". I don't necessarily understand what that really does, but AFAICT if my C function returns nothing, the do_dotcall's retval should simply remain set to R_NilValue, which should be fine. I must be misunderstanding something here, but I don't know what,...

...Rprintf("\n\n"); } I see that the values of MatCovInv[k] have changed. Valgrind shows the following error on the second block of Rprintf: Later Cov Extra 3 0x107df7fb8 ==954== Invalid read of size 8 ==954== at 0xA92D599: NPHDPHMM (in /Users/NPHDPHMM.so) ==954== by 0x8632A: do_dotcall (dotcode.c:652) ==954== by 0xB036A: Rf_eval (eval.c:657) ==954== by 0xBE8C0: do_set (eval.c:2028) ==954== by 0xB0404: Rf_eval (eval.c:629) ==954== by 0xBE3C4: do_begin (eval.c:1638) ==954== by 0xB0404: Rf_eval (eval.c:629) ==954== by 0xBB95D: Rf_applyClosure (eval.c:1038) ==954==...

...EXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*) (in /home/therneau/Rlib/lme4/libs/lme4.so) ==31901== by 0xD8727F1: merPredDCreate (in /home/therneau/Rlib/lme4/libs/lme4.so) ==31901== by 0x80C0B9E: R_doDotCall (dotcode.c:648) ==31901== by 0x80C159F: do_dotcall (dotcode.c:1252) ==31901== by 0x80FFABA: Rf_eval (eval.c:728) ==31901== by 0x810308A: do_set (eval.c:2579) ==31901== by 0x80FF907: Rf_eval (eval.c:700) ==31901== Address 0xe310828 is 0 bytes after a block of size 2,408 alloc'd ==31901== at 0x402A6DC: operator new(unsigned int) (in...

...EC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, > SEXPREC*) (in /home/therneau/Rlib/lme4/libs/lme4.so) > ==31901== by 0xD8727F1: merPredDCreate (in > /home/therneau/Rlib/lme4/libs/lme4.so) > ==31901== by 0x80C0B9E: R_doDotCall (dotcode.c:648) > ==31901== by 0x80C159F: do_dotcall (dotcode.c:1252) > ==31901== by 0x80FFABA: Rf_eval (eval.c:728) > ==31901== by 0x810308A: do_set (eval.c:2579) > ==31901== by 0x80FF907: Rf_eval (eval.c:700) > ==31901== Address 0xe310828 is 0 bytes after a block of size 2,408 alloc'd > ==31901== at 0x402A6DC: operat...

...out + 172 (layout.c:464) 5 grid.so 0x060ca888 calcViewportTransform + 1296 (viewport.c:356) 6 grid.so 0x060be0a0 doSetViewport + 256 (grid.c:200) 7 grid.so 0x060be5ac L_setviewport + 76 (grid.c:311) 8 libR.dylib 0x00249318 do_dotcall + 652 (dotcode.c:770) 9 libR.dylib 0x0024cc7c do_dotcallgr + 80 (dotcode.c:1450) 10 libR.dylib 0x00263b24 Rf_eval + 1536 (eval.c:405) 11 libR.dylib 0x00265b1c do_set + 224 (eval.c:1309)

...#39;files' must be character This happens in Windows versions of R-patched and R-devel. Charlie Geyer was bitten by this in his fuzzyRankTests package (version 0.3), which fails check because of it on Windows, but not on Unix. I haven't done any testing on Unix. I've traced into the do_dotcall function in src/main/dotcode.c, and I see that on the second call the "symbol.symbol.call" member is NULL, so no test is done, but I don't see why this is happening. The resolveNativeRoutine function does some strange stuff. Duncan Murdoch

...0x15e65f1d 0x15e5d000 + 36637 4 randtoolbox.so 0x15e614ef fill_array32 + 4038 5 randtoolbox.so 0x15e6513d SFmersennetwister + 335 6 randtoolbox.so 0x15e652c6 doSFMersenneTwister + 255 7 libR.dylib 0x00367a52 do_dotcall + 1394 8 libR.dylib 0x0038b5a2 Rf_eval + 1754 9 libR.dylib 0x0038f9a2 do_set + 592 10 libR.dylib 0x0038b366 Rf_eval + 1182 11 libR.dylib 0x0038b366 Rf_eval + 1182 12 libR.dylib 0x0038c140 do_b...

...0x15e65f1d 0x15e5d000 + 36637 4 randtoolbox.so 0x15e614ef fill_array32 + 4038 5 randtoolbox.so 0x15e6513d SFmersennetwister + 335 6 randtoolbox.so 0x15e652c6 doSFMersenneTwister + 255 7 libR.dylib 0x00367a52 do_dotcall + 1394 8 libR.dylib 0x0038b5a2 Rf_eval + 1754 9 libR.dylib 0x0038f9a2 do_set + 592 10 libR.dylib 0x0038b366 Rf_eval + 1182 11 libR.dylib 0x0038b366 Rf_eval + 1182 12 libR.dylib 0x0038c140 do_b...

...nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 Call stack: 100DEC2F R.dll:100DEC2F SET_TAG 100E0527 R.dll:100E0527 Rf_allocVector 100E0D37 R.dll:100E0D37 R_alloc 100F2ACA R.dll:100F2ACA vmmin 023F5E96 gem.dll:023F5E96 weibullMH 10088C33 R.dll:10088C33 do_dotcall 100B8827 R.dll:100B8827 Rf_eval 100BA4D2 R.dll:100BA4D2 do_set 100B86CB R.dll:100B86CB Rf_eval 100BA5D5 R.dll:100BA5D5 do_begin 100B86CB R.dll:100B86CB Rf_eval 100BB8EB R.dll:100BB8EB Rf_applyClosure 100B85F8 R.dll:100B85F8 Rf_eval 100BA4D2 R.dll:100BA4D2 do_set 100B86CB R.dll:100B...

...0 ebx=00000000 ecx=00000000 edx=10e51fe0 esi=00000000 edi=003e3d08 eip=77c13730 esp=0022d5ac ebp=0022d7f8 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 Call stack: 77C13730 msvcrt.dll:77C13730 strlen 004C799D R.dll:004C799D do_dotcall 004DA35F R.dll:004DA35F Rf_eval 004DC2D5 R.dll:004DC2D5 do_set 004DA3C8 R.dll:004DA3C8 Rf_eval 004DBA52 R.dll:004DBA52 do_begin 004DA3C8 R.dll:004DA3C8 Rf_eval 004DA6B5 R.dll:004DA6B5 Rf_applyClosure 004DA1D7 R.dll:004DA1D7 Rf_eval 004DA949 R.dll:004DA949 Rf_applyClosure 004DAC5A R...

...d 13,332,140 bytes. ==8682== ==8682== 56 bytes in 1 blocks are possibly lost in loss record 15 of 55 ==8682== at 0x40045EB: calloc (vg_replace_malloc.c:279) ==8682== by 0x805AA60: R_chk_calloc (memory.c:2368) ==8682== by 0x57C89D6: RODBCDriverConnect (RODBC.c:244) ==8682== by 0x8160A68: do_dotcall (dotcode.c:863) ==8682== by 0x81857CE: Rf_eval (eval.c:489) ==8682== by 0x81895B7: do_set (eval.c:1420) ==8682== by 0x81855B0: Rf_eval (eval.c:463) ==8682== by 0x818631E: do_begin (eval.c:1172) ==8682== by 0x81855B0: Rf_eval (eval.c:463) ==8682== by 0x81879B4: Rf_applyClosure (eva...

Good morning! The descriptions of memory protection all assume that one is calling a C-function directly from R. I'm not sure if my understanding of calling a C-function from another C-function is correct: Suppose there are two functions SEXP bar(SEXP y) { SEXP b; PROTECT(b = allocVector(...)); ... computations on b UNPROTECT(1); return b } and SEXP foo(SEXP x) { SEXP a;

Hi all, I've just been working with a piece of fortran code (Leo Breiman's random forest code) that needs a lot of arguments. When I use .Fortran, I get the message 'too many arguments in foreign function call'. Neither the help page for .Fortran (actually Foreign) nor "Writing R Extensions" explains how many arguments are too many. Looking at the code in

Hi all, I've just been working with a piece of fortran code (Leo Breiman's random forest code) that needs a lot of arguments. When I use .Fortran, I get the message 'too many arguments in foreign function call'. Neither the help page for .Fortran (actually Foreign) nor "Writing R Extensions" explains how many arguments are too many. Looking at the code in

...n 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, useNRows=0x90b02c8) at RODBC.c:277 #8 0x08161a19 in do_dotcall (call=0x89b9ba8, op=0x85518dc, args=<value optimized out>, env=0x9100e44) at dotcode.c:863 #9 0x0818683f in Rf_eval (e=0x89b9ba8, rho=0x9100e44) at eval.c:489 #10 0x0818a628 in do_set (call=0x89b9b1c, op=0x8546120, args=<value optimized out>, rho=0x9100e44) at eval.c:1424 #11 0x081...

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("

OK, to summarize and clarify a bit 1) I downloaded some code that existed in "pure" FORTRAN, FORTRAN+S-Plus, and FORTRAN+R versions. 2) I discovered that the primary difference between R and S-Plus version was the use of a wrapper to reduce the number of arguments from 87 to 65. When I inquired why, the author of the code replied "R won't take more than 65 arguments to

...920f7864 zdotc_ + 60 2 libRlapack.dylib 0x013701a0 zhetd2_ + 960 3 libRlapack.dylib 0x0136fcdc zhetrd_ + 1900 4 libRlapack.dylib 0x01370ad8 zheev_ + 1016 5 lapack.so 0x010a4038 modLa_rs_cmplx + 392 6 libR.dylib 0x003c99e8 La_rs_cmplx + 72 7 libR.dylib 0x00372380 do_dotcall + 16864 8 libR.dylib 0x003a170c Rf_eval + 1804 9 libR.dylib 0x003a14dc Rf_eval + 1244 10 libR.dylib 0x003a45f4 do_set + 980 11 libR.dylib 0x003a14dc Rf_eval + 1244 12 libR.dylib 0x003a2b08 do_begin + 104 13 libR.dylib 0x003a14dc Rf_eval + 1244 14 l...