On Sun, Aug 21, 2005 at 01:45:37PM -0400, Justin Pryzby wrote:
> > hmm - aside from the cosmetic issue you reported with libXt (an overlapping
> > memcpy is just that), what other warnings are you seeing with valgrind?
> Right; its cosmetic because the obvious implementation of memcpy is:
>
> for ( ; n; n--) {
> *dest++ = *src++;
> }
>
> However, the manpage _says_: "The memory areas should not overlap.",
> and so it is probably best to make no assumptions about its
> implementation.
true. But in this case, valgrind is just pointing out that the code is
inefficient. (I don't recall what I was working on when I fixed it in
libXt, but it was something that valgrind reported then).
> Invalid reads and writes. I've attached the output of `valgrind
> --log-file=xterm-valgrind ./xterm`, resizing the xterm to LINES=1, and
> running top -d.3.
>
> > (and of course, what version of xterm,
> We should probably have a bugscript to include xterm's version in
> reports.. cloning now.
"xterm -v" gives the information
(and it doesn't try to open the display ;-)
> It appears to be:
>
> ++<LI><A HREF="#xterm_200">Patch #200 - 2005/2/6 - XFree86 4.4.99.23</A>
>
> > what size is "super-small", etc).
> LINES=1. In fact, I just ran `echo $LINES` in a 1 line xterm, and it
> crashed (or, something did, anyway). (It didn't crash under valgrind,
> though).
yes - that's expected behavior. A 1-line xterm "can't" scroll, since
scrolling regions have to be at least 2 lines. The earlier bug fix exposed
this hole.
I do use valgrind - the last I recall is that the only unaccounted problems
are in glibc when the locale isn't POSIX.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Attachment:
pgpv6tERc3hXu.pgp
Description: PGP signature