From ripley at stats.ox.ac.uk  Sat Oct 11 21:44:06 2008
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Sat, 11 Oct 2008 20:44:06 +0100 (BST)
Subject: [Rd] seg.fault from nlme::gnls() {was "[R-sig-ME] GNLS Crash"}
In-Reply-To: <329A68716B57D54E8D39FD3F8A4A84DF0EB93FB9@um-mail0136.unimaas.nl>
References: <329A68716B57D54E8D39FD3F8A4A84DF0EB93FB9@um-mail0136.unimaas.nl>
Message-ID: <alpine.LFD.2.00.0810112039250.8667@gannet.stats.ox.ac.uk>

Supplying a tested patch to the current nlme sources (on this list) would 
be the most effective way to get people's attention: otherwise it will be 
very low priority.

And please don't cross-post.

On Thu, 9 Oct 2008, Viechtbauer Wolfgang (STAT) wrote:

> Hello All,
>
> I just wanted to bring this back again to the attention of the list(s) just to see if this issue can be resolved (but I'll understand if the development of the new mixed-model functions would take precedence over this).
>
> Best,
>
> -- 
> Wolfgang Viechtbauer
> ?Department of Methodology and Statistics
> ?University of Maastricht, The Netherlands
> ?http://www.wvbauer.com/
>
>
>
> ----Original Message----
> From: William Dunlap [mailto:wdunlap at tibco.com]
> Sent: Monday, September 29, 2008 21:03
> To: Martin Maechler; Viechtbauer Wolfgang (STAT)
> Cc: r-sig-mixed-models at r-project.org; R-devel at stat.math.ethz.ch
> Subject: RE: [Rd] seg.fault from nlme::gnls() {was "[R-sig-ME] GNLS
> Crash"}
>
>>  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: r-devel-bounces at r-project.org
>> [mailto:r-devel-bounces at r-project.org] On Behalf Of Martin Maechler
>> Sent: Saturday, September 27, 2008 2:20 AM
>> To: Viechtbauer Wolfgang (STAT)
>> Cc: r-sig-mixed-models at r-project.org; R-devel at stat.math.ethz.ch
>> Subject: [Rd] seg.fault from nlme::gnls() {was "[R-sig-ME] GNLS
>> Crash"}
>>
>>>>>>> "VW" == Viechtbauer Wolfgang (STAT)
>>>>>>>     <Wolfgang.Viechtbauer at STAT.unimaas.nl> 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/
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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


[Rd] seg.fault from nlme::gnls() {was "[R-sig-ME] GNLS Crash"}
Prof Brian Ripley