If you call gctorture(TRUE) the error happens immediately,
at the same place.
2064 PROTECT(tmp = lengthgets(this->data, ++this->len));
Is this a case where PROTECT_WITH_INDEX() and REPROTECT()
need to be used (in connections.c)? Could lengthgets (used
by the SET_LENGTH() macro) be changed to propogate the protection
status? It looks like it always requires protection tricks
to use.
Bill
On Tue, 29 Apr 2008, 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:10000) {
> > 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
> 2064 PROTECT(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
360-428-8146
"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
