thr3ads.net - R help - [R] Spare some CPU cycles for testing lme? [Sep 2004]

If this information is useful, please help other people find it:
Share via:

Frank Samuelson

2004-Sep-13 12:40 UTC

[R] Spare some CPU cycles for testing lme?

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("  ",i,"\r")
     0
})

The above code simply reruns the example from the
lme help page a large number of times and returns a bunch
of 0's, so you'll need to have the lme4 and Matrix
packages installed.  It might take a while to complete,
but you can always nice it and let it run.

I'm attempting to bootstrap lme() from the lme4 package,
but it causes a
segfault after a couple hundred iterations.  This happens on
my Linux x86 RedHat 7.3, 8.0, 9.0, FC1 systems w/ 1.9.1
and devel 2.0.0 (not all possible combinations actually
tested.)
I've communicated w/ Douglas Bates about this and he
doesn't appear to have the problem.

Thanks for any help.

-Frank

james.holtman@convergys.com

2004-Sep-13 14:13 UTC

head link

[R] Spare some CPU cycles for testing lme?

I tried out your example and it abended.

It ran through 22472 times and ended with an error message that the
instruction at 0x77f5b2ab could not reference location 0x00000028.
> version         _
platform i386-pc-mingw32
arch     i386
os       mingw32
system   i386, mingw32
status
major    1
minor    9.1
year     2004
month    06
day      21
language R

HTH
__________________________________________________________
James Holtman        "What is the problem you are trying to solve?"
Executive Technical Consultant  --  Office of Technology, Convergys
james.holtman at convergys.com
+1 (513) 723-2929



                      Frank Samuelson
                      <fws4 at cdrh.fda.gov>          To:       r-help at
stat.math.ethz.ch
                      Sent by:                     cc:
                      r-help-bounces at stat.m        Subject:  [R] Spare some
CPU cycles for testing lme?
                      ath.ethz.ch


                      09/13/2004 08:40






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("  ",i,"\r")
     0
})

The above code simply reruns the example from the
lme help page a large number of times and returns a bunch
of 0's, so you'll need to have the lme4 and Matrix
packages installed.  It might take a while to complete,
but you can always nice it and let it run.

I'm attempting to bootstrap lme() from the lme4 package,
but it causes a
segfault after a couple hundred iterations.  This happens on
my Linux x86 RedHat 7.3, 8.0, 9.0, FC1 systems w/ 1.9.1
and devel 2.0.0 (not all possible combinations actually
tested.)
I've communicated w/ Douglas Bates about this and he
doesn't appear to have the problem.

Thanks for any help.

-Frank

______________________________________________
R-help at stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html

Marc Schwartz

2004-Sep-13 14:31 UTC

head link

[R] Spare some CPU cycles for testing lme?

On Mon, 2004-09-13 at 07:40, Frank Samuelson wrote:> 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("  ",i,"\r")
>      0
> })
> 
> The above code simply reruns the example from the
> lme help page a large number of times and returns a bunch
> of 0's, so you'll need to have the lme4 and Matrix
> packages installed.  It might take a while to complete,
> but you can always nice it and let it run.
> 
> I'm attempting to bootstrap lme() from the lme4 package,
> but it causes a
> segfault after a couple hundred iterations.  This happens on
> my Linux x86 RedHat 7.3, 8.0, 9.0, FC1 systems w/ 1.9.1
> and devel 2.0.0 (not all possible combinations actually
> tested.)
> I've communicated w/ Douglas Bates about this and he
> doesn't appear to have the problem.
> 
> Thanks for any help.
> 
> -Frank
> 
Replicated here on FC 2 running:

Version 1.9.1 Patched (2004-09-07)

The backtrace from gdb follows. It would probably make sense to move
this thread to r-devel. As you can see, it got through 10,546 runs
before segfaulting.

cc: to Doug.

HTH,

Marc Schwartz

> dump<-sapply( 1:50000, function(i) {+      fm <- lme(langPOST ~ IQ.ver.cen + avg.IQ.ver.cen, data = bdf,
+                random = ~ IQ.ver.cen | schoolNR);
+      cat("  ",i,"\r")
+      0
+ })
   10546
Program received signal SIGSEGV, Segmentation fault.
0x00982242 in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0x00982242 in _int_free () from /lib/tls/libc.so.6
#1  0x0098373b in free () from /lib/tls/libc.so.6
#2  0x080c4003 in ReleaseLargeFreeVectors () at memory.c:695
#3  0x080c5999 in RunGenCollect (size_needed=1144) at memory.c:1282
#4  0x080c7084 in R_gc_internal (size_needed=1144) at memory.c:1933
#5  0x080c6b67 in Rf_allocVector (type=16, length=2287) at memory.c:1788
#6  0x0809b6b1 in Rf_duplicate (s=0xbed5d40) at duplicate.c:150
#7  0x0809b335 in Rf_duplicate (s=0xb64a3bc) at duplicate.c:100
#8  0x0809b517 in Rf_duplicate (s=0xbed15a8) at duplicate.c:142
#9  0x0809b777 in Rf_duplicate (s=0xb3f6048) at duplicate.c:137
#10 0x080a796d in EnsureLocal (symbol=0x9719f38, rho=0xb64c2b8) at
eval.c:765
#11 0x080a8691 in evalseq (expr=0x9719f38, rho=0xb64c2b8, forcelocal=1,
tmploc=0xb64a340) at eval.c:1135
#12 0x080a8847 in applydefine (call=0x97f9818, op=0x9705264,
args=0x97f9834, rho=0xb64c2b8) at eval.c:1199
#13 0x080a7055 in Rf_eval (e=0x97f9818, rho=0xb64c2b8) at eval.c:375
#14 0x080a8436 in do_begin (call=0x97f97fc, op=0x9705168,
args=0x97f97e0, rho=0xb64c2b8) at eval.c:1046
#15 0x080a7055 in Rf_eval (e=0x97f97fc, rho=0xb64c2b8) at eval.c:375
#16 0x080a7055 in Rf_eval (e=0x97f9bdc, rho=0xb64c2b8) at eval.c:375
#17 0x080a8436 in do_begin (call=0x97f4ac8, op=0x9705168,
args=0x97f9bc0, rho=0xb64c2b8) at eval.c:1046
#18 0x080a7055 in Rf_eval (e=0x97f4ac8, rho=0xb64c2b8) at eval.c:375
#19 0x080a7301 in Rf_applyClosure (call=0xb64c130, op=0x97f9a8c,
arglist=0xb64c050, rho=0xb65989c,
    suppliedenv=0xb64c0f8) at eval.c:566
#20 0x080cd2fb in applyMethod (call=0xb64c130, op=0x97f9a8c,
args=0xb64c050, rho=0xb65989c, newrho=0xb64c0f8)
    at objects.c:119
#21 0x080cd985 in Rf_usemethod (generic=0x81a1f2b "[", obj=0xb3ebbc0,
call=0x9a668f0, args=0xb64c050,
    rho=0xb65989c, callrho=0xb65989c, defrho=0x96f6338, ans=0xfef58728)
at objects.c:326
#22 0x080a994d in Rf_DispatchOrEval (call=0x9a668f0, op=0x9705050,
generic=0x81a1f2b "[", args=0xb64bffc,
    rho=0xb65989c, ans=0xfef58728, dropmissing=0, argsevald=1) at
eval.c:1719
#23 0x0811d5aa in do_subset (call=0x9a668f0, op=0x9705050,
args=0x9a66944, rho=0xb65989c) at subset.c:504
#24 0x080a7055 in Rf_eval (e=0x9a668f0, rho=0xb65989c) at eval.c:375
#25 0x080a8bc3 in do_set (call=0x9a66880, op=0x9705264, args=0x9a668b8,
rho=0xb65989c) at eval.c:1271
#26 0x080a7055 in Rf_eval (e=0x9a66880, rho=0xb65989c) at eval.c:375
---Type <return> to continue, or q <return> to quit---
#27 0x080a8436 in do_begin (call=0x9a67184, op=0x9705168,
args=0x9a66864, rho=0xb65989c) at eval.c:1046
#28 0x080a7055 in Rf_eval (e=0x9a67184, rho=0xb65989c) at eval.c:375
#29 0x080a7055 in Rf_eval (e=0x9a66c44, rho=0xb65989c) at eval.c:375
#30 0x080a8436 in do_begin (call=0x9a66b10, op=0x9705168,
args=0x9a66c28, rho=0xb65989c) at eval.c:1046
#31 0x080a7055 in Rf_eval (e=0x9a66b10, rho=0xb65989c) at eval.c:375
#32 0x080a7301 in Rf_applyClosure (call=0xb659730, op=0x9a67900,
arglist=0xb65a558, rho=0xb65966c,
    suppliedenv=0xb6596f8) at eval.c:566
#33 0x080cd2fb in applyMethod (call=0xb659730, op=0x9a67900,
args=0xb65a558, rho=0xb65966c, newrho=0xb6596f8)
    at objects.c:119
#34 0x080cd985 in Rf_usemethod (generic=0x9b1f300 "model.matrix",
obj=0xb415a64, call=0x9a6783c,
    args=0x96f6338, rho=0xb65966c, callrho=0xb415bb4, defrho=0xa038100,
ans=0xfef59288) at objects.c:326
#35 0x080cdd45 in do_usemethod (call=0x9a6783c, op=0x9713ca8,
args=0x9a67874, env=0xb65966c) at objects.c:389
#36 0x080a7055 in Rf_eval (e=0x9a6783c, rho=0xb65966c) at eval.c:375
#37 0x080a7301 in Rf_applyClosure (call=0xa9e8b04, op=0x9a677cc,
arglist=0xb65a558, rho=0xb415bb4,
    suppliedenv=0x96f6338) at eval.c:566
#38 0x080a6e60 in Rf_eval (e=0xa9e8b04, rho=0xb415bb4) at eval.c:410
#39 0x080a6d8b in Rf_eval (e=0xb65a328, rho=0xb65a408) at eval.c:354
#40 0x080a6d8b in Rf_eval (e=0xb65a4b0, rho=0xb65a408) at eval.c:354
#41 0x0806c791 in do_bind (call=0x9733fb8, op=0x9707e44, args=0xb65a4cc,
env=0xb65a408) at bind.c:877
#42 0x080cd029 in do_internal (call=0xa20, op=0x9706418, args=0x9733fd4,
env=0xb65a408) at names.c:1057
#43 0x080a7055 in Rf_eval (e=0x9733f2c, rho=0xb65a408) at eval.c:375
#44 0x080a8436 in do_begin (call=0x9734060, op=0x9705168,
args=0x9733f10, rho=0xb65a408) at eval.c:1046
#45 0x080a7055 in Rf_eval (e=0x9734060, rho=0xb65a408) at eval.c:375
#46 0x080a7301 in Rf_applyClosure (call=0xa9e8acc, op=0x9733e30,
arglist=0xb65a344, rho=0xb415bb4,
    suppliedenv=0x96f6338) at eval.c:566
#47 0x080a6e60 in Rf_eval (e=0xa9e8acc, rho=0xb415bb4) at eval.c:410
#48 0x080a8d8a in Rf_evalList (el=0xa9e8ab0, rho=0xb415bb4) at
eval.c:1360
#49 0x080a6f7d in Rf_eval (e=0xa9e8a94, rho=0xb415bb4) at eval.c:396
#50 0x080a8d8a in Rf_evalList (el=0xa9e8a78, rho=0xb415bb4) at
eval.c:1360
#51 0x080a97c0 in Rf_DispatchOrEval (call=0xa9e9868, op=0x9706788,
generic=0x8181b21 "c", args=0xa9e9884,
    rho=0xb415bb4, ans=0xfef5a278, dropmissing=1, argsevald=0) at
eval.c:1735
---Type <return> to continue, or q <return> to quit---
#52 0x0806be69 in do_c (call=0xa9e9868, op=0x9706788, args=0xa9e9884,
env=0xb415bb4) at bind.c:562
#53 0x080a7055 in Rf_eval (e=0xa9e9868, rho=0xb415bb4) at eval.c:375
#54 0x080a8bc3 in do_set (call=0xa9e9814, op=0x9705264, args=0xa9e9830,
rho=0xb415bb4) at eval.c:1271
#55 0x080a7055 in Rf_eval (e=0xa9e9814, rho=0xb415bb4) at eval.c:375
#56 0x080a8436 in do_begin (call=0xa9e9d28, op=0x9705168,
args=0xa9e97f8, rho=0xb415bb4) at eval.c:1046
#57 0x080a7055 in Rf_eval (e=0xa9e9d28, rho=0xb415bb4) at eval.c:375
#58 0x080a755d in R_execClosure (call=0xb4167f0, op=0xae393ac,
arglist=0xb4162a4, rho=0xb631a38,
    newrho=0xb415bb4) at eval.c:651
#59 0x080a7813 in R_execMethod (op=0xae393ac, rho=0xb41649c) at
eval.c:753
#60 0x00f86763 in R_standardGeneric (fname=0xacd6c40, ev=0xb41649c,
fdef=0xb41657c)
    at methods_list_dispatch.c:610
#61 0x080cf6dc in do_standardGeneric (call=0xacd89d8, op=0x9713c00,
args=0xb41657c, env=0xb41649c)
    at objects.c:982
#62 0x080a6fe3 in Rf_eval (e=0xacd89d8, rho=0xb41649c) at eval.c:398
#63 0x080a7301 in Rf_applyClosure (call=0xb4167f0, op=0xaca9a34,
arglist=0xb4162a4, rho=0xb631a38,
    suppliedenv=0x96f6338) at eval.c:566
#64 0x080a6e60 in Rf_eval (e=0xb4167f0, rho=0xb631a38) at eval.c:410
#65 0x080a948c in do_eval (call=0x98a581c, op=0x97100c8, args=0xb416138,
rho=0xb4160e4) at eval.c:1541
#66 0x080cd029 in do_internal (call=0x2f00, op=0x9706418,
args=0xb416138, env=0xb4160e4) at names.c:1057
#67 0x080a7055 in Rf_eval (e=0x98a5790, rho=0xb4160e4) at eval.c:375
#68 0x080a7301 in Rf_applyClosure (call=0xa9ecfd8, op=0x98a6644,
arglist=0xb41603c, rho=0xb4179c0,
    suppliedenv=0x96f6338) at eval.c:566
#69 0x080a6e60 in Rf_eval (e=0xa9ecfd8, rho=0xb4179c0) at eval.c:410
#70 0x080a8d8a in Rf_evalList (el=0xa9ecfbc, rho=0xb4179c0) at
eval.c:1360
#71 0x080a6f7d in Rf_eval (e=0xa9ecf84, rho=0xb4179c0) at eval.c:396
#72 0x080a8436 in do_begin (call=0xa9ecd54, op=0x9705168,
args=0xa9ecf68, rho=0xb4179c0) at eval.c:1046
#73 0x080a7055 in Rf_eval (e=0xa9ecd54, rho=0xb4179c0) at eval.c:375
#74 0x080a755d in R_execClosure (call=0xb41889c, op=0xae39770,
arglist=0xb418094, rho=0xb631a38,
    newrho=0xb4179c0) at eval.c:651
#75 0x080a7813 in R_execMethod (op=0xae39770, rho=0xb41828c) at
eval.c:753
#76 0x00f86763 in R_standardGeneric (fname=0xacd6c40, ev=0xb41828c,
fdef=0xb418388)
---Type <return> to continue, or q <return> to quit---
    at methods_list_dispatch.c:610
#77 0x080cf6dc in do_standardGeneric (call=0xacd89d8, op=0x9713c00,
args=0xb418388, env=0xb41828c)
    at objects.c:982
#78 0x080a6fe3 in Rf_eval (e=0xacd89d8, rho=0xb41828c) at eval.c:398
#79 0x080a7301 in Rf_applyClosure (call=0xb41889c, op=0xaca9a34,
arglist=0xb418094, rho=0xb631a38,
    suppliedenv=0x96f6338) at eval.c:566
#80 0x080a6e60 in Rf_eval (e=0xb41889c, rho=0xb631a38) at eval.c:410
#81 0x080a948c in do_eval (call=0x98a581c, op=0x97100c8, args=0xb417f28,
rho=0xb418e68) at eval.c:1541
#82 0x080cd029 in do_internal (call=0x2f00, op=0x9706418,
args=0xb417f28, env=0xb418e68) at names.c:1057
#83 0x080a7055 in Rf_eval (e=0x98a5790, rho=0xb418e68) at eval.c:375
#84 0x080a7301 in Rf_applyClosure (call=0xa9dd984, op=0x98a6644,
arglist=0xb418dc0, rho=0xb631498,
    suppliedenv=0x96f6338) at eval.c:566
#85 0x080a6e60 in Rf_eval (e=0xa9dd984, rho=0xb631498) at eval.c:410
#86 0x080a8d8a in Rf_evalList (el=0xa9dd968, rho=0xb631498) at
eval.c:1360
#87 0x080a6f7d in Rf_eval (e=0xa9dd930, rho=0xb631498) at eval.c:396
#88 0x080a8436 in do_begin (call=0xa9de368, op=0x9705168,
args=0xa9dd914, rho=0xb631498) at eval.c:1046
#89 0x080a7055 in Rf_eval (e=0xa9de368, rho=0xb631498) at eval.c:375
#90 0x080a755d in R_execClosure (call=0xafc54a0, op=0xae3994c,
arglist=0xb631a8c, rho=0xb631a38,
    newrho=0xb631498) at eval.c:651
#91 0x080a7813 in R_execMethod (op=0xae3994c, rho=0xb631c84) at
eval.c:753
#92 0x00f86763 in R_standardGeneric (fname=0xacd6c40, ev=0xb631c84,
fdef=0xb630dd0)
    at methods_list_dispatch.c:610
#93 0x080cf6dc in do_standardGeneric (call=0xacd89d8, op=0x9713c00,
args=0xb630dd0, env=0xb631c84)
    at objects.c:982
#94 0x080a6fe3 in Rf_eval (e=0xacd89d8, rho=0xb631c84) at eval.c:398
#95 0x080a7301 in Rf_applyClosure (call=0xafc54a0, op=0xaca9a34,
arglist=0xb631a8c, rho=0xb631a38,
    suppliedenv=0x96f6338) at eval.c:566
#96 0x080a6e60 in Rf_eval (e=0xafc54a0, rho=0xb631a38) at eval.c:410
#97 0x080a8bc3 in do_set (call=0xafc54f4, op=0x9705264, args=0xafc54d8,
rho=0xb631a38) at eval.c:1271
#98 0x080a7055 in Rf_eval (e=0xafc54f4, rho=0xb631a38) at eval.c:375
#99 0x080a8436 in do_begin (call=0xafc5510, op=0x9705168,
args=0xafc552c, rho=0xb631a38) at eval.c:1046
---Type <return> to continue, or q <return> to quit---
#100 0x080a7055 in Rf_eval (e=0xafc5510, rho=0xb631a38) at eval.c:375
#101 0x080a7301 in Rf_applyClosure (call=0xafc5280, op=0xafc5a50,
arglist=0xb631a00, rho=0xafc4c28,
    suppliedenv=0x96f6338) at eval.c:566
#102 0x080a6e60 in Rf_eval (e=0xafc5280, rho=0xafc4c28) at eval.c:410
#103 0x0805f297 in do_lapply (call=0x990c12c, op=0x9711180, args=0x2933,
rho=0xafc4c28) at apply.c:60
#104 0x080cd029 in do_internal (call=0x3480, op=0x9706418,
args=0x990c19c, env=0xafc4c28) at names.c:1057
#105 0x080a7055 in Rf_eval (e=0x990c0a0, rho=0xafc4c28) at eval.c:375
#106 0x080a8bc3 in do_set (call=0x990c04c, op=0x9705264, args=0x990c068,
rho=0xafc4c28) at eval.c:1271
#107 0x080a7055 in Rf_eval (e=0x990c04c, rho=0xafc4c28) at eval.c:375
#108 0x080a8436 in do_begin (call=0x990c43c, op=0x9705168,
args=0x990c030, rho=0xafc4c28) at eval.c:1046
#109 0x080a7055 in Rf_eval (e=0x990c43c, rho=0xafc4c28) at eval.c:375
#110 0x080a7301 in Rf_applyClosure (call=0x99f649c, op=0x990ccb4,
arglist=0xafc4b80, rho=0xafc591c,
    suppliedenv=0x96f6338) at eval.c:566
#111 0x080a6e60 in Rf_eval (e=0x99f649c, rho=0xafc591c) at eval.c:410
#112 0x080a8bc3 in do_set (call=0x99f6448, op=0x9705264, args=0x99f6464,
rho=0xafc591c) at eval.c:1271
#113 0x080a7055 in Rf_eval (e=0x99f6448, rho=0xafc591c) at eval.c:375
#114 0x080a8436 in do_begin (call=0x99f56e4, op=0x9705168,
args=0x99f642c, rho=0xafc591c) at eval.c:1046
#115 0x080a7055 in Rf_eval (e=0x99f56e4, rho=0xafc591c) at eval.c:375
#116 0x080a7301 in Rf_applyClosure (call=0xafc5778, op=0x99f6e1c,
arglist=0xafc583c, rho=0x9716e0c,
    suppliedenv=0x96f6338) at eval.c:566
#117 0x080a6e60 in Rf_eval (e=0xafc5778, rho=0x9716e0c) at eval.c:410
#118 0x080a8bc3 in do_set (call=0xafc57cc, op=0x9705264, args=0xafc57b0,
rho=0x9716e0c) at eval.c:1271
#119 0x080a7055 in Rf_eval (e=0xafc57cc, rho=0x9716e0c) at eval.c:375
#120 0x080c1ba7 in Rf_ReplIteration (rho=0x9716e0c,
savestack=-1070969512, browselevel=0, state=0xfef5dd40)
    at main.c:250
#121 0x080c1d4f in R_ReplConsole (rho=0x9716e0c, savestack=0,
browselevel=0) at main.c:298
#122 0x080c25d3 in run_Rmainloop () at main.c:656
#123 0x0812478c in main (ac=1, av=0xfef5e254) at system.c:99

end of backtrace.

Tamas K Papp

2004-Sep-13 23:47 UTC

head link

[R] Spare some CPU cycles for testing lme?

On Mon, Sep 13, 2004 at 08:40:15AM -0400, Frank Samuelson wrote:
> 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("  ",i,"\r")
>     0
> })
Hi,

It ran smoothly on my installation.
> version           _                      
platform powerpc-apple-darwin6.8
arch     powerpc                
os       darwin6.8              
system   powerpc, darwin6.8     
status                          
major    1                      
minor    9.1                    
year     2004                   
month    06                     
day      21                     
language R                      

Typical lines from top (if it helps anything; around 45-50k
iterations):

1225 R.bin       90.7%  2:55:12   1    62  1164  71.7M+ 13.7M  66.6M+  228M+
1225 R.bin       78.6%  3:18:27   1    62  1606  81.3M+ 13.7M  75.5M+  234M+

Best,

Tamas

Thomas Schönhoff

2004-Sep-14 06:55 UTC

head link

[R] Spare some CPU cycles for testing lme?

Hello,

Frank Samuelson schrieb:
> 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("  ",i,"\r")
>     0
> })
>
>I also tested your code by using R-1.91 under Debian Sid. After hundreds 
of iterations it ended up with the already noticed "segmentation
fault"

HTH

Thomas

Prof Brian D Ripley

2004-Sep-14 12:09 UTC

head link

[R] Spare some CPU cycles for testing lme?

As others have said, this needs tools not CPU cycles: gctorture or valgrind.

Valgrind found (after a few seconds and on the first pass)

==23057== Invalid read of size 4
==23057==    at 0x3CF4E645: ssc_symbolic_permute (Mutils.c:373)
==23057==    by 0x3CF5BF75: ssclme_create (ssclme.c:168)
==23057==    by 0x80AF5E8: do_dotcall
(/users/ripley/R/svn/R-devel/src/main/dotcode.c:640)
==23057==    by 0x80CFA84: Rf_eval
(/users/ripley/R/svn/R-devel/src/main/eval.c:399)
==23057==  Address 0x3C7F3BD0 is 4 bytes before a block of size 524 alloc'd
==23057==    at 0x3C01CB56: calloc (in
/opt/local/lib/valgrind/vgpreload_memcheck.so)
==23057==    by 0x80F9EBE: R_chk_calloc
(/users/ripley/R/svn/R-devel/src/main/memory.c:2151)
==23057==    by 0x3CF4E515: ssc_symbolic_permute (Mutils.c:352)
==23057==    by 0x3CF5BF75: ssclme_create (ssclme.c:168)
==23057===23057== Use of uninitialised value of size 8
==23057==    at 0x80C0137: Rf_duplicate
(/users/ripley/R/svn/R-devel/src/main/duplicate.c:160)
==23057==    by 0x80BFA85: Rf_duplicate
(/users/ripley/R/svn/R-devel/src/main/duplicate.c:101)
==23057==    by 0x80BFEB3: Rf_duplicate
(/users/ripley/R/svn/R-devel/src/main/duplicate.c:154)
==23057==    by 0x816ED96: do_subset2_dflt
(/users/ripley/R/svn/R-devel/src/main/subset.c:816)
==23057===23057== Conditional jump or move depends on uninitialised value(s)
==23057==    at 0x3CF62229: ssclme_fitted (ssclme.c:1587)
==23057==    by 0x80AF646: do_dotcall
(/users/ripley/R/svn/R-devel/src/main/dotcode.c:646)
==23057==    by 0x80CFA84: Rf_eval
(/users/ripley/R/svn/R-devel/src/main/eval.c:399)
==23057==    by 0x80D1D80: do_set
(/users/ripley/R/svn/R-devel/src/main/eval.c:1280)

which is pretty definitive evidence of a problem (possibly 2) in the code.

I strongly recommend valgrind (http://valgrind.kde.org/) if you are using
x86 Linux.  It has found quite a few errors in R and in certain packages
recently.  The only thing to watch is that optimized BLASes will probably
crash it.


On Mon, 13 Sep 2004, Frank Samuelson wrote:
> 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("  ",i,"\r")
>      0
> })
>
> The above code simply reruns the example from the
> lme help page a large number of times and returns a bunch
> of 0's, so you'll need to have the lme4 and Matrix
> packages installed.  It might take a while to complete,
> but you can always nice it and let it run.
>
> I'm attempting to bootstrap lme() from the lme4 package,
> but it causes a
> segfault after a couple hundred iterations.  This happens on
> my Linux x86 RedHat 7.3, 8.0, 9.0, FC1 systems w/ 1.9.1
> and devel 2.0.0 (not all possible combinations actually
> tested.)
> I've communicated w/ Douglas Bates about this and he
> doesn't appear to have the problem.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

John Christie

2004-Sep-14 23:56 UTC

head link

[R] Spare some CPU cycles for testing lme?

On Sep 13, 2004, at 8:47 PM, Tamas K Papp wrote:
> It ran smoothly on my installation.
>
>> version
>          _
> platform powerpc-apple-darwin6.8
> arch     powerpc
> os       darwin6.8
> system   powerpc, darwin6.8
> status
> major    1
> minor    9.1
> year     2004
> month    06
> day      21
> language R
>
> Typical lines from top (if it helps anything; around 45-50k
> iterations):
>
> 1225 R.bin       90.7%  2:55:12   1    62  1164  71.7M+ 13.7M  66.6M+  
> 228M+
> 1225 R.bin       78.6%  3:18:27   1    62  1606  81.3M+ 13.7M  75.5M+  
> 234M+
I can confirm this.  same installation

Apparently Analagous Threads

Search for more seemingly similar threads

R help - Sep 2004 - Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

[R] Spare some CPU cycles for testing lme?

Apparently Analagous Threads