[Rd] knnFinder package

2008-01-14 Thread Gregoire Pau
Dear all,

I have found some serious bugs in the knnFinder package (which supports 
data structures and algorithms for both exact and approximate nearest 
neighbor searching in arbitrarily high dimensions) that may trigger 
segmentation faults.
I have fixed them but I had troubles to contact its maintainer Samuel E. 
Kemp (previously with the University of Glamorgan, UK). Do someone know 
where I can reach him ?

Best regards,

Greg
---
Gregoire Pau
EMBL/EBI Cambridge, UK
http://www.ebi.ac.uk/~gpau

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] reproducible segmentation fault caused by textConnection()

2008-04-29 Thread Gregoire Pau

Dear all,

It seems that textConnection() can trigger a segmentation fault. The
following script (using two large loops) makes this bug reproducible:

for (i in 1:1) {
  z=textConnection(NULL,open='w')
  for (j in 1:100) {
write(runif(1)*1e6,file=z)
write('\n',file=z)
  }
  close(z)
}

The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest 
R-devel 2008-04-29 r45543.

Here are some sessionInfo() details:
**
R version 2.6.1 (2007-11-26)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
**
R version 2.7.0 (2008-04-22)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices datasets  utils methods   base
**
R version 2.8.0 Under development (unstable) (2008-04-29 r45543)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices datasets  utils methods   base

Greg
---
Gregoire Pau
EMBL/EBI Cambridge, UK
http://www.ebi.ac.uk/~gpau

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] reproducible segmentation fault caused by textConnection()

2008-04-30 Thread Gregoire Pau

Dear Bill,

Thanks for having had a look on this bug. I am now using an anonymous 
file() connection to store my stuffs instead of textConnection(): it is 
much faster and doesn't raise any seg faults.


Regards,

Greg
---
Gregoire Pau
EMBL/EBI Cambridge, UK
http://www.ebi.ac.uk/~gpau

Bill Dunlap wrote:

On Tue, 29 Apr 2008, Gregoire Pau wrote:


Dear all,

It seems that textConnection() can trigger a segmentation fault. The
following script (using two large loops) makes this bug reproducible:

for (i in 1:1) {
   z=textConnection(NULL,open='w')
   for (j in 1:100) {
 write(runif(1)*1e6,file=z)
 write('\n',file=z)
   }
   close(z)
}

The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest
R-devel 2008-04-29 r45543.


valgrind shows that it uses freed memory after
a garbage collecting episode (after many iterations),
because a Routtextconn's 'data' component was freed:

   ==24210== Invalid read of size 1
   ==24210==at 0x810B328: Rf_lengthgets (Rinlinedfuns.h:358)
   ==24210==by 0x8121C48: text_vfprintf (connections.c:2064)
   ==24210==by 0x809D0C1: Rvprintf (printutils.c:770)
   ==24210==by 0x809D105: Rprintf (printutils.c:668)
   ==24210==by 0x810A984: do_cat (builtin.c:617)
   ==24210==  Address 0x5823CD8 is 0 bytes inside a block of size 1,176 free'd
   ==24210==at 0x40052A3: free (vg_replace_malloc.c:233)
   ==24210==by 0x805AC3D: R_gc_internal (memory.c:769)
   ==24210==by 0x805B873: Rf_cons (memory.c:1757)
   ==24210==by 0x81571F6: Rf_promiseArgs (eval.c:1633)

   (gdb) where 5
   #0  Rf_lengthgets (x=0x5823cd8, len=289)
   at ../../src/include/Rinlinedfuns.h:358
   #1  0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
ap=0xbef18b84 "�\213�") at connections.c:2064
   #2  0x0809d0c2 in Rvprintf (format=0x81e64d8 "\n", arg=0xbef18b84 "�\213�")
   at printutils.c:770
   #3  0x0809d106 in Rprintf (format=0x81e64d8 "\n") at printutils.c:668
   #4  0x0810a985 in do_cat (call=0x4ae31f0, op=0x4104eec, args=0x55bb2bc,
   rho=0x55baf20) at builtin.c:617
   (More stack frames follow...)
   (gdb) up
   #1  0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
   ap=0xbef18b84 "�\213�") at connections.c:2064
   2064PROTECT(tmp = lengthgets(this->data, ++this->len));
   (gdb) print this->data
   $1 = 0x5823cd8
   (gdb) whatis this
   type = Routtextconn
   (gdb) whatis this->data
   type = SEXP
   (gdb) print *this->data
   $2 = {sxpinfo = {type = 16, obj = 0, named = 2, gp = 0, mark = 0, debug = 0,
 trace = 0, spare = 0, gcgen = 0, gccls = 7}, attrib = 0x40ae088,
 gengc_next_node = 0x8235270, gengc_prev_node = 0x8235270, u = {primsxp = {
 offset = 288}, symsxp = {pname = 0x120, value = 0x0,
 internal = 0x57685c0}, listsxp = {carval = 0x120, cdrval = 0x0,
 tagval = 0x57685c0}, envsxp = {frame = 0x120, enclos = 0x0,
 hashtab = 0x57685c0}, closxp = {formals = 0x120, body = 0x0,
 env = 0x57685c0}, promsxp = {value = 0x120, expr = 0x0,
 env = 0x57685c0}}}



Bill Dunlap
Insightful Corporation
bill at insightful dot com

 "All statements in this message represent the opinions of the author and do
 not necessarily reflect Insightful Corporation policy or position."


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel