On 08/10/2012 12:04 PM, peter dalgaard wrote:
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.
actually valgrind complains a lot about rJava, though that can be
confusing; the example reproduces, so amenable to investigation. glmulti
doesn't have C code and the only unusual dependency is rJava
> sessionInfo()
R version 2.15.1 Patched (2012-06-22 r59603)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmulti_1.0.4 rJava_0.9-3
Here's the stack trace starting a little below the top
#21190 0x00007ffff78b3b88 in Rf_usemethod (generic=0x9f0c80 "terms",
obj=0xbcd040, call=0xbf6fb0, args=0x604d18, rho=0xbd9e70,
callrho=0xbf88e8, defrho=0x1a873f0,
ans=0x7fffffffb1a8) at
/home/mtmorgan/src/R-2-15-branch/src/main/objects.c:339
339 *ans = applyMethod(t, sxp, matchedarg, rho, newrho);
(gdb)
#21189 0x00007ffff78b3009 in applyMethod (call=0xbca188, op=0xbf67f0,
args=0xbdad30, rho=0xbd9e70, newrho=0xbca118) at
/home/mtmorgan/src/R-2-15-branch/src/main/objects.c:125
125 ans = applyClosure(call, op, args, rho, newrho);
(gdb)
#21188 0x00007ffff784c574 in Rf_applyClosure (call=0xbca188,
op=0xbf67f0, arglist=0xbdad30, rho=0xbd9e70, suppliedenv=0xbca118)
at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:859
859 PROTECT(tmp = eval(body, newrho));
(gdb)
#21187 0x00007ffff784b4b5 in Rf_eval (e=0xbf52e0, rho=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
(gdb)
#21186 0x00007ffff784e12d in do_begin (call=0xbf52e0, op=0x610710,
args=0xbee388, rho=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1413
1413 s = eval(CAR(args), rho);
(gdb)
#21185 0x00007ffff784b4b5 in Rf_eval (e=0xbee3c0, rho=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
(gdb)
#21184 0x00007ffff784ef32 in do_set (call=0xbee3c0, op=0x610908,
args=0xbedbc8, rho=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1715
1715 s = eval(CADR(args), rho);
(gdb)
#21183 0x00007ffff784b4b5 in Rf_eval (e=0xbedc70, rho=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
(gdb)
#21182 0x00007ffff78b2979 in do_internal (call=0xbedc70, op=0x611620,
args=0xbc9518, env=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/names.c:1228
1228 ans = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env);
(gdb)
#21181 0x00007ffff78acdea in do_termsform (call=0xbedf48, op=0x6329f0,
args=0xbc9518, rho=0xbc8f30) at
/home/mtmorgan/src/R-2-15-branch/src/main/model.c:838
838 PROTECT(formula = EncodeVars(CAR(args)));
(gdb)
#21180 0x00007ffff78ac4e6 in EncodeVars (formula=0xbcd040) at
/home/mtmorgan/src/R-2-15-branch/src/main/model.c:629
629 return EncodeVars(CADDR(formula));
(gdb)
#21179 0x00007ffff78ac5c5 in EncodeVars (formula=0xbcd2a8) at
/home/mtmorgan/src/R-2-15-branch/src/main/model.c:641
641 return CrossTerms(CADR(formula), CADDR(formula));
(gdb)
#21178 0x00007ffff78abafb in CrossTerms (left=0xbcd318, right=0xd7e338)
at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:459
459 PROTECT(left = EncodeVars(left));
(gdb)
#21177 0x00007ffff78ac5c5 in EncodeVars (formula=0xbcd318) at
/home/mtmorgan/src/R-2-15-branch/src/main/model.c:641
641 return CrossTerms(CADR(formula), CADDR(formula));
(gdb)
#21176 0x00007ffff78abc24 in CrossTerms (left=0xbc5558, right=0x16b6e78)
at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:471
471 return TrimRepeats(left);
(gdb)
#21175 0x00007ffff78ab934 in TrimRepeats (list=0xbc5558) at
/home/mtmorgan/src/R-2-15-branch/src/main/model.c:404
404 SETCDR(list, TrimRepeats(StripTerm(CAR(list), CDR(list))));
(gdb)
#21174 0x00007ffff78ab88d in StripTerm (term=0x121c1d8, list=0xbc5590)
at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:385
385 tail = StripTerm(term, CDR(list));
and so on down to the bottom
valgrind says this
==14352== Invalid write of size 4
==14352== at 0xD4BC2BD: ???
==14352== by 0xD4AC437: ???
==14352== by 0xBDE21AE: JavaCalls::call_helper(JavaValue*,
methodHandle*, JavaCallArguments*, Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDE1A44: JavaCalls::call(JavaValue*, methodHandle,
JavaCallArguments*, Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDA5A7E:
instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*)
(in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDA5AF9:
instanceKlass::call_class_initializer(Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDA5CF1:
instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDA6168: instanceKlass::initialize(Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDA5FB2:
instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBDA6168: instanceKlass::initialize(Thread*) (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xC0BDB8D: Threads::create_vm(JavaVMInitArgs*, bool*)
(in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== by 0xBE00509: JNI_CreateJavaVM (in
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==14352== Address 0x7feff31e0 is not stack'd, malloc'd or (recently) free'd
-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.weyla...@gmail.com>
wrote:
On Aug 9, 2012, at 9:14 PM, David Winsemius <dwinsem...@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-h...@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-h...@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.
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
