[R] debug vs regular mode

peter dalgaard pdalgd at gmail.com
Fri Aug 10 21:04:55 CEST 2012


Not to spoil your fun, but this is getting a bit off-topic for R-help. If you wish to continue the debugging process in public, I think you should move to R-devel. 

Also, it sounds like the problem is in the glmulti package, so you might want to involve its maintainer at some point.

-pd 

On Aug 10, 2012, at 19:51 , Zhang, Peng wrote:

> Thanks! It is interesting that Windows has pointed the problem to Java. 
> So it is probable that how I did my debug led me to the wrong direction.
> 
> Since I was unsure how to debug S4 class, I copied the source implement 
> R function from glmulti package into my testing program.
> 
> The segmentation fault will appear when I step to "neotete = 
> terms(as.formula(paste("h~",paste(preds, collapse="*"))))". That is why 
> I have asked my initial question on the board.
> 
> The more interesting thing is that if I don't run library(glmulti), but 
> just the following lines, I won't have problem when I stepped to that 
> terms function.
> 
> I am totally lost. It is not clear to me how to debug S4 class.
> 
> Best,
> Peng
> 
> ### beginning
> library(glmulti)
> 
> testdata = cbind(Y=rnorm(100), data.frame(matrix(rnorm(100*50), ncol = 50)))
> 
> glmulti =
> function(y, xr, data, exclude, name, intercept, marginality , bunch, 
> chunk, chunks,
>         level, minsize, maxsize, minK, maxK, 
> method,crit,confsetsize,popsize,mutrate,
>         sexrate,imm, plotty,  report, deltaM, deltaB, conseq, 
> fitfunction, resumefile, includeobjects, ...) {
>     if (missing(data))
>         tete = terms(y)
>     else
>         tete = terms(y, data=data)
>     oo = attr(tete,"order")
>     dep = as.character(attr(tete,"variables"))[2]
>     int = attr(tete,"intercept")
>     preds = as.character(attr(tete,"variables"))[-(1:2)]
>     if (level==2 && max(oo)>1) {
>         # get all possible interactions
>         interac = attr(tete,"term.labels")[oo==2]
>         neotete = terms(as.formula(paste("h~",paste(preds, collapse="*"))))
>         neointerac= attr(neotete,"term.labels")[attr(neotete,"order")==2]
>         # get exclusions
>         for (i in interac)
>             neointerac=neointerac[neointerac!=i]
>         # same for main effects
>         mama = attr(tete,"term.labels")[oo==1]
>         exma = preds
>         for (j in mama)
>             exma = exma[exma!=j]
>         exma = c(exma,neointerac)
>     } else {
>         preds = attr(tete,"term.labels")[oo==1]
>         exma=c(1)
>     }
>     call = match.call()
>     call[[match("y", names(call))]] = dep
>     call[[length(names(call))+1]] = preds
>     names(call)[length(names(call))] ="xr"
>         call[[length(names(call))+1]] = exma
>     names(call)[length(names(call))] ="exclude"
> 
>     if (missing(data)) {
>         call[[length(names(call))+1]] = environment(y)
>         names(call)[length(names(call))] ="data"
>     }
>     eval(call)
> }
> 
> debug(glmulti)
> 
> glmulti(Y~(X1+X2+X3+X4+X5+X6+X7+X8+X9+X10+X11+X12+X13+X14+X15)*X16, 
> xr=NULL, data = testdata, level = 2)
> ###end
> 
> On 08/10/2012 11:47 AM, Henric (Nilsson) Winell wrote:
>> On 2012-08-10 15:42, Zhang, Peng wrote:
>> 
>>> You are right. I am running Arch Linux. However, I obtained a
>>> segmentation directly, so didn't know where to find the bug??
>>> 
>>>> library("glmulti")
>>> Loading required package: rJava
>>>> testdata = cbind(Y=rnorm(100), data.frame(matrix(rnorm(100*50), ncol
>>> = 50)))
>>>> glmulti(Y~(X1+X2+X3+X4+X5+X6+X7+X8+X9+X10+X11+X12+X13+X14+X15)*X16,
>>> data= testdata, level = 2)
>>> Segmentation fault
>>> 
>>> Is this information "Error in .jnew("glmulti/ModelGenerator", y,
>>> jarray(xc), .jarray(xq),  : java.lang.ArrayIndexOutOfBoundsException:
>>> 15" only in Windows, or did you see it under Fedora as well?
>> 
>> Windows only.  Fedora just returned "Segmentation fault".
>> 
>> 
>> //Henric
>> 
>> 
>> 
>>> 
>>> Thank you!
>>> 
>>> Peng
>>> 
>>> BTW:
>>> 
>>> $ uname -a
>>> Linux Precision 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST
>>> 2012 x86_64 GNU/Linux
>>> 
>>>> sessionInfo()
>>> R version 2.15.1 (2012-06-22)
>>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>> 
>>> locale:
>>>   [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>>>   [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>>   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>>   [7] LC_PAPER=C                 LC_NAME=C
>>>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>> 
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods base
>>> 
>>> 
>>> On 08/10/2012 09:25 AM, Henric (Nilsson) Winell wrote:
>>>> On 2012-08-10 06:10, Zhang, Peng wrote:
>>>> 
>>>>> Thanks to both for your reply.
>>>>> 
>>>>> library(glmulti)
>>>>> testdata = cbind(Y=rnorm(100), data.frame(matrix(rnorm(100*50), ncol
>>>>> = 50)))
>>>>> glmulti(Y~(X1+X2+X3+X4+X5+X6+X7+X8+X9+X10+X11+X12+X13+X14+X15)*X16, 
>>>>> data
>>>>> = testdata, level = 2)
>>>>> 
>>>>> This is reproducible to get a segmentation fault.
>>>> 
>>>> There's some information missing here, notably the output from
>>>> 'sessionInfo()', but I guess this is under GNU/Linux.  I can confirm a
>>>> seg. fault under Fedora FC17 x86_64.
>>>> 
>>>> Under Windows 7 64-bit, however, we get some further info:
>>>> 
>>>>> library("glmulti")
>>>> Loading required package: rJava
>>>>> testdata = cbind(Y=rnorm(100), data.frame(matrix(rnorm(100*50), ncol
>>>> = 50)))
>>>>> glmulti(Y~(X1+X2+X3+X4+X5+X6+X7+X8+X9+X10+X11+X12+X13+X14+X15)*X16,
>>>> data
>>>> + = testdata, level = 2)
>>>> Initialization...
>>>> Error in .jnew("glmulti/ModelGenerator", y, .jarray(xc), 
>>>> .jarray(xq),  :
>>>>   java.lang.ArrayIndexOutOfBoundsException: 15
>>>>> 
>>>>> sessionInfo()
>>>> R version 2.15.1 Patched (2012-08-06 r60178)
>>>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>>> 
>>>> locale:
>>>> [1] LC_COLLATE=Swedish_Sweden.1252 LC_CTYPE=Swedish_Sweden.1252
>>>> [3] LC_MONETARY=Swedish_Sweden.1252 LC_NUMERIC=C
>>>> [5] LC_TIME=Swedish_Sweden.1252
>>>> 
>>>> attached base packages:
>>>> [1] stats     graphics  grDevices utils     datasets  methods base
>>>> 
>>>> other attached packages:
>>>> [1] glmulti_1.0.4 rJava_0.9-3
>>>>> 
>>>> 
>>>> So, this doesn't seem to be a bug in R and is thus likely to need the
>>>> attention of the 'glmulti' package's maintainer.
>>>> 
>>>> 
>>>> HTH,
>>>> Henric
>>>> 
>>>> 
>>>> 
>>>>> But I have troubles to
>>>>> extract the exact information from this S4 class to make a simpler
>>>>> example because of my limited knowledge on S4 class. The author of the
>>>>> package is busy at the moment, and does not have time to look into it.
>>>>> 
>>>>> Peng
>>>>> 
>>>>> On 08/09/2012 10:25 PM, R. Michael Weylandt 
>>>>> <michael.weylandt at gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> On Aug 9, 2012, at 9:14 PM, David Winsemius <dwinsemius at comcast.net>
>>>>>> wrote:
>>>>>> 
>>>>>>> On Aug 9, 2012, at 4:56 PM, Zhang, Peng wrote:
>>>>>>> 
>>>>>>>> Dear all,
>>>>>>>> 
>>>>>>>> I had a R segmentation fault, and then invoked debug mode and ran
>>>>>>>> step
>>>>>>>> by step.
>>>>>>> 
>>>>>>>> 2. Why does the same function behave differently under debug and
>>>>>>>> regular
>>>>>>>> mode?
>>>>>>> I cannot help you there.
>>>>>>> 
>>>>>> Though a reproducible segfault is certainly worth a bug report if
>>>>>> you can do so, in debug or regular modes.
>>>>>> 
>>>>>> You may wish to search stackoverflow for tips on how to make a great
>>>>>> reproducible example in R.
>>>>>> 
>>>>>> Michael
>>>>> **********************************************************
>>>>> Electronic Mail is not secure, may not be read every day, and should
>>>>> not be used for urgent or sensitive issues
>>>>> 
>>>>> ______________________________________________
>>>>> R-help at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>>> PLEASE do read the posting guide
>>>>> http://www.R-project.org/posting-guide.html
>>>>> and provide commented, minimal, self-contained, reproducible code.
>>>>> 
>>>> 
>>> **********************************************************
>>> Electronic Mail is not secure, may not be read every day, and should 
>>> not be used for urgent or sensitive issues
>>> 
>>> 
>> 
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues 
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com



More information about the R-help mailing list