I've managed to trap the following segfault with xxgdb and gctorture() set.
The
segfault seems to move around if gctorture() is not set, but has now occurred
twice
in the same spot with it set. xxgdb gives the message
Program received signal SIGSEGV, Segmentation fault.
0x71244 in RunGenCollect (size_needed=2) at memory.c:1027
and the source listing points to FORWARD_CHILDREN(s); in the following section
from
src/main/memory.c
#ifndef EXPEL_OLD_TO_NEW
/* scan nodes in uncollected old generations with old-to-new pointers */
for (gen = num_old_gens_to_collect; gen < NUM_OLD_GENERATIONS; gen++)
for (i = 0; i < NUM_NODE_CLASSES; i++)
for (s = NEXT_NODE(R_GenHeap[i].OldToNew[gen]);
s != R_GenHeap[i].OldToNew[gen];
s = NEXT_NODE(s))
FORWARD_CHILDREN(s);
#endif
I'm using> version
_
platform sparc-sun-solaris2.6
arch sparc
os solaris2.6
system sparc, solaris2.6
status Patched
major 1
minor 2.1
year 2001
month 02
day 06
language R
Paul Gilbert
P.S. If someone can quickly tell me the trick to make cut and paste work with
xxgdb
in Solaris I would appreciate it. (I realize I should probably read the manual,
but
if it is simple please let me know.)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:> I've managed to trap the following segfault with xxgdb and gctorture() set. The > segfault seems to move around if gctorture() is not set, but has now occurred twice > in the same spot with it set. xxgdb gives the message > > Program received signal SIGSEGV, Segmentation fault. > 0x71244 in RunGenCollect (size_needed=2) at memory.c:1027 > > and the source listing points to FORWARD_CHILDREN(s); in the following section from > src/main/memory.c > > #ifndef EXPEL_OLD_TO_NEW > /* scan nodes in uncollected old generations with old-to-new pointers */ > for (gen = num_old_gens_to_collect; gen < NUM_OLD_GENERATIONS; gen++) > for (i = 0; i < NUM_NODE_CLASSES; i++) > for (s = NEXT_NODE(R_GenHeap[i].OldToNew[gen]); > s != R_GenHeap[i].OldToNew[gen]; > s = NEXT_NODE(s)) > FORWARD_CHILDREN(s); > #endif >This just shows that something corrupted the memory handling. The actual bug is probably somewhat prior to this. If you do a "bt" (backtrace) and go "up" a couple of times, you might find a spot where someone forgot to PROTECT() a newly created R object.> P.S. If someone can quickly tell me the trick to make cut and paste work with xxgdb > in Solaris I would appreciate it. (I realize I should probably read the manual, but > if it is simple please let me know.)I gave up on xxgdb long ago because I thought it was enough to have to deal with bugs in our own programs! However, it would seem that the ordinary mousing techniques works as usual on Linux. Command-line recall appears to be shot, however. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
A few people suggested ddd might be preferred to xxgdb, where upon xxgdb crashed on me. I have now managed to get ddd working on my linux box at home, but am still having some difficulty at work. (It requires a newer c++ , some *tif libraries, etc.) ---- Peter D. writes:>The actual bug is probably somewhat prior to this. If you do a "bt" >(backtrace) and go "up" a couple of times, you might find a spot where >someone forgot to PROTECT() a newly created R object.Well ddd still does not install the innocent with the knowlege of C programmers so I am guessing a bit about exactly what I should be looking for. If I do "up" a few times I see a section of main/dotcode.c starting at line 180 (copied below) that looks like it might have a problem. The first few cases do not have any PROTECT statements and others do. If this is not a a good guess then perhaps someone could fill me in on what statements that create new R objects look like. Thanks, Paul _____ case INTSXP: s = allocVector(type, n); iptr = (int*)p; for(i=0 ; i<n ; i++) { INTEGER(s)[i] = iptr[i]; } break; case REALSXP: s = allocVector(type, n); if(asLogical(getAttrib(arg, CSingSymbol)) == 1) { sptr = (float*) p; for(i=0 ; i<n ; i++) REAL(s)[i] = (double) sptr[i]; } else { rptr = (double*) p; for(i=0 ; i<n ; i++) REAL(s)[i] = rptr[i]; } break; case CPLXSXP: s = allocVector(type, n); zptr = (Rcomplex*)p; for(i=0 ; i<n ; i++) { COMPLEX(s)[i] = zptr[i]; } break; case STRSXP: if(Fort) { /* only return one string: warned on the R -> Fortran step */ strncpy(buf, (char*)p, 255); buf[256] = '\0'; PROTECT(s = allocVector(type, 1)); SET_STRING_ELT(s, 0, mkChar(buf)); UNPROTECT(1); } else ... -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._