andy@cit-vlsi.ai.mit.edu (Andy Fyfe) (06/16/89)
[running on a sun3, sunos 3.5]
The routine init_terminal_io calls "xmalloc" but never "free". It gets
called, it seems, with every (or at least many) SIGWINCH, and in no time
you can have a *VERY* large data segment. Included is a patch changing
the xmalloc to alloca. (Then again, maybe it would be best to just
allocate a fixed buffer?)
On the suns,
$ echo '\'
\UUUU
Where do the U's come from?
*** save/readline.c Thu Jun 15 19:04:05 1989
--- readline.c Thu Jun 15 19:04:09 1989
***************
*** 1234,1240 ****
return;
}
! buffer = (char *)xmalloc (2048);
BC = tgetstr ("pc", &buffer);
PC = buffer ? *buffer : 0;
BC = tgetstr ("le", &buffer);
--- 1234,1240 ----
return;
}
! buffer = (char *)alloca (2048);
BC = tgetstr ("pc", &buffer);
PC = buffer ? *buffer : 0;
BC = tgetstr ("le", &buffer);chet@kiwi.CWRU.EDU (Chet Ramey) (06/17/89)
In article <8906160229.AA05556@cit-vlsi> andy@cit-vlsi.ai.mit.edu (Andy Fyfe) writes: >[running on a sun3, sunos 3.5] >On the suns, > $ echo '\' > \UUUU > >Where do the U's come from? The U's are the range-checking bytes written after a block of space by the bash malloc(). It would appear that you have a pointer problem somewhere; however, I cannot reproduce it. This particular example works fine on my vax (running Ultrix 3.0), my sun-3 running sunos 3.5, my IBM-RT running AOS 4.3, and my other IBM-RT running AIX 2.2.1: cwns1$ echo '\' \ cwns1$ Chet Chet Ramey Network Services Group, CWRU chet@cwjcc.INS.CWRU.Edu "The flagon with the dragon has the potion with the poison; the vessel with the pestle holds the brew that is true!"
chet@kiwi.CWRU.EDU (Chet Ramey) (06/17/89)
In article <8906160229.AA05556@cit-vlsi> andy@cit-vlsi.ai.mit.edu (Andy Fyfe) writes: >[running on a sun3, sunos 3.5] >The routine init_terminal_io calls "xmalloc" but never "free". It gets >called, it seems, with every (or at least many) SIGWINCH, and in no time >you can have a *VERY* large data segment. Included is a patch changing >the xmalloc to alloca. (Then again, maybe it would be best to just >allocate a fixed buffer?) [ He gives a fix that changes the call to xmalloc to a call to alloca ] Looking at the code, I don't see why the xmalloc is required at all. A couple of lines before the xmalloc takes place, buffer is intialized to point at term_string_buffer, which is a static buffer of 2048 chars. I took the call to xmalloc out of my version and don't seem to have suffered any ill effects. Chet Chet Ramey Network Services Group, CWRU chet@cwjcc.INS.CWRU.Edu "The flagon with the dragon has the potion with the poison; the vessel with the pestle holds the brew that is true!"