When I run this under valgrind with gctorture(TRUE) I see memory
misuse in mat_mult (matrix.c, line 82): % R-2.8.0-dev
--debugger=valgrind --debugger-args=--db-attach=yes ... copyright
blah blah ...
data(Orange)
gctorture(TRUE)
gnls(circumference ~ Asym/(1 + exp(-(age-xmid)/scal)) ,
+ data = Orange, correlation = corExp(form = ~1 | Tree),
+ start = c(Asym=150, xmid=750, scal=300))
r==5894== Invalid read of size 4
==5894== at 0x580268F: mult_mat (matrix.c:82)
==5894== by 0x57FF1B0: corStruct_recalc (corStruct.c:70)
==5894== by 0x5801F89: gnls_objective (gnls.c:100)
==5894== by 0x58020FE: fit_gnls (gnls.c:152)
==5894== by 0x81439A2: do_dotCode (dotcode.c:1758)
==5894== by 0x8161C56: Rf_eval (eval.c:487)
==5894== by 0x81637D5: do_set (eval.c:1422)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
==5894== by 0x816384B: do_begin (eval.c:1174)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
==5894== by 0x816397B: do_repeat (eval.c:1137)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
==5894== Address 0x4E4A8CC is 12 bytes inside a block of size 864
free'd ==5894== at 0x40052A3: free (vg_replace_malloc.c:233)
==5894== by 0x805ACFD: R_gc_internal (memory.c:767)
==5894== by 0x805B933: Rf_cons (memory.c:1755)
==5894== by 0x805B98E: Rf_allocList (memory.c:2094)
==5894== by 0x815AB4C: replaceCall (Rinlinedfuns.h:84)
==5894== by 0x8163476: applydefine (eval.c:919)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
==5894== by 0x816384B: do_begin (eval.c:1174)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
==5894== by 0x816384B: do_begin (eval.c:1174)
==5894== by 0x8161B3B: Rf_eval (eval.c:461)
My copy of valgrind doesn't get along with my copy of gdb,
so when it pops into gdb the debugger doesn't get any information
from *.so files. I don't have the time now to put printf statements
into mat_mult.
Bill Dunlap
wdunlap tibco.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Maechler
Sent: Saturday, September 27, 2008 2:20 AM
To: Viechtbauer Wolfgang (STAT)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Rd] seg.fault from nlme::gnls() {was "[R-sig-ME] GNLS
Crash"}
"VW" == Viechtbauer Wolfgang (STAT)
<[EMAIL PROTECTED]> on Fri, 26 Sep 2008
18:00:19 +0200 writes:
Hi all, I'm trying to fit a marginal (longitudinal)
model with an exponential serial correlation function to
the Orange tree data set. However, R crashes frequently
when using the gnls() function. With the following
simple example, I was able to reproduce the problem.
gnls.exp <- gnls(circumference ~ Asym/(1 + exp(-(age-xmid)/scal)) ,
data = Orange, correlation = corExp(form = ~1 | Tree),
start = c(Asym=150, xmid=750, scal=300))
Yes, I can reproduce it (on a Linux (RHEL 5) 64bit server), using R
2.8.0 alpha : Use this
for(i in 1:20)# for MM: ca. 8 to 10 times --> seg.fault try( gnls.exp
<- gnls(circumference ~ Asym/(1 +
exp(-(age-xmid)/scal)) , data = Orange, correlation =
corExp(form = ~1 | Tree), start = c(Asym=150, xmid=750, scal=300)) )
If I run it in the debugger and then do a backtrace I see
Error in gnls(circumference ~ Asym/(1 + exp(-(age - xmid)/scal)),
data = Orange, : Step halving factor reduced below minimum in NLS
step
[............................................................]
[...................the same about 6 times...................]
[............................................................]
Error in gnls(circumference ~ Asym/(1 + exp(-(age - xmid)/scal)),
data = Orange, : Step halving factor reduced below minimum in NLS
step Error in .makeMessage(..., domain = domain) : incorrect number
of arguments to "<-"
Error in .makeMessage(..., domain = domain) :
incorrect number of arguments to "<-"
Program received signal SIGABRT, Aborted.
0x0000003294e30155 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003294e30155 in raise () from /lib64/libc.so.6
#1 0x0000003294e31bf0 in abort () from /lib64/libc.so.6
#2 0x00000000004184f5 in R_gc_internal (size_needed=0)
at ../../../R/src/main/memory.c:761
#3 0x000000000041b121 in Rf_cons (car=0x1b2ec088, cdr=0x1a3436d8)
at ../../../R/src/main/memory.c:1755
#4 0x0000000000578472 in applydefine (call=<value optimized out>,
op=0x1a3617a8, args=0x1ad47590, rho=0x1b2ea428)
at ../../../R/src/include/Rinlinedfuns.h:153
#5 0x0000000000575a42 in Rf_eval (e=0x1ad47558, rho=0x1b2ea428)
at ../../../R/src/main/eval.c:461
#6 0x0000000000576d50 in do_begin (call=0x1ad48450, op=0x1a362518,
args=0x1ad47520, rho=0x1b2ea428) at
../../../R/src/main/eval.c:1174 #7 0x0000000000575a42 in Rf_eval
(e=0x1ad48450, rho=0x1b2ea428) at ../../../R/src/main/eval.c:461 #8
0x0000000000578f9c in Rf_applyClosure (call=0x1b2e9958,
op=0x1ad48370, arglist=0x1b2e9a70, rho=0x1b690298,
suppliedenv=0x1b2e99c8) at ../../../R/src/main/eval.c:667 #9
0x00000000004285b9 in Rf_usemethod (generic=0x67e8d7 "[",
obj=<value optimized out>, call=<value optimized out>,
args=<value optimized out>, rho=0xffffffffffffffff,
callrho=0x1b690298, defrho=0x1a384f28, ans=0x7fffcaa8d5a8) at
../../../R/src/main/objects.c:311 #10 0x0000000000576a25 in
Rf_DispatchOrEval (call=0x1a81d8d0, op=0x1a3622e8,
generic=0x67e8d7 "[", args=0x1a81d908, rho=0x1b690298,
ans=0x7fffcaa8d5a8, dropmissing=0, argsevald=0) at
../../../R/src/main/eval.c:1930 #11 0x00000000004afc40 in
do_subset (call=0x7716, op=0x7716, args=0xffffffffffffffff,
rho=0x1b690298) at ../../../R/src/main/subset.c:577 #12
0x0000000000575a42 in Rf_eval (e=0x1a81d8d0, rho=0x1b690298) at
../../../R/src/main/eval.c:461 #13 0x00000000005780c7 in applydefine
(call=0x1a81d748, op=0x1a3617a8, args=0x6,
rho=0xffffffffffffffff) at ../../../R/src/main/eval.c:1318 #14
0x0000000000575a42 in Rf_eval (e=0x1a81d748, rho=0x1b690298) at
../../../R/src/main/eval.c:461 #15 0x00000000005775de in do_for
(call=0x1a81d668, op=0x1a360180, args=0x1a81d6a0, rho=0x1b690298) at
../../../R/src/main/eval.c:1073
..... and more (downto #155 for R's main(...)
This is a bug, probably in the C code of package nlme which I guess
corrupts memory somehere earlier, and we are seeing the effect only
later. I'll leave this to the (memory-)debugging experts...
Martin
On my and one other computer, R usually crashes when calling the
gnls() function with this code three times in a row. I stumbled
across this when trying to fit this model with different starting
values.
Version information:
platform i386-pc-mingw32
......
version.string R version 2.7.2 (2008-08-25)
Can anybody help figure out what causes this problem?
Best,
--
Wolfgang Viechtbauer
Department of Methodology and Statistics
University of Maastricht, The Netherlands
http://www.wvbauer.com/
