completion on brace + 4 characters doesn't work

completion on brace + 4 characters doesn't work

[Vincent Lefevre]

Hi,

I've just found the following problem:

$ zsh-beta -f
xvii% echo $ZSH_VERSION 
4.3.11-dev-2-cvs0421
xvii% ls -a            
.  ..  abcdef
xvii% echo ./{abcd

Here when I hit [Tab], nothing is completed. However, the completion
works if I remove the d.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Bart Schaefer]

On Apr 28,  1:11pm, Vincent Lefevre wrote:
} 
} $ zsh-beta -f
} xvii% echo $ZSH_VERSION 
} 4.3.11-dev-2-cvs0421

ZSH_PATCHLEVEL is more useful now because it doesn't include any local
modifications (like "-cvs0421") that are meaningless to those of us
who aren't involved with whatever precompiled package one may have
installed.

} xvii% ls -a            
} .  ..  abcdef
} xvii% echo ./{abcd
} 
} Here when I hit [Tab], nothing is completed. However, the completion
} works if I remove the d.

If you're starting from zsh -f then this is the old compctl which is
pretty much unmaintained at this point.

However, I'm not able to reproduce this problem on my CentOS 4 box:

torch% echo $ZSH_VERSION $ZSH_PATCHLEVEL
4.3.11-dev-2 1.5265
torch% ls -a
.  ..  abcdef
torch% echo ./{abcdef,

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-28 08:12:40 -0700, Bart Schaefer wrote:
> On Apr 28,  1:11pm, Vincent Lefevre wrote:
> } 
> } $ zsh-beta -f
> } xvii% echo $ZSH_VERSION 
> } 4.3.11-dev-2-cvs0421
> 
> ZSH_PATCHLEVEL is more useful now because it doesn't include any local
> modifications (like "-cvs0421") that are meaningless to those of us
> who aren't involved with whatever precompiled package one may have
> installed.

OK: 1.5256

under Debian.

But the same problem occurs with Debian's 4.3.11 zsh package.

> } xvii% ls -a            
> } .  ..  abcdef
> } xvii% echo ./{abcd
> } 
> } Here when I hit [Tab], nothing is completed. However, the completion
> } works if I remove the d.
> 
> If you're starting from zsh -f then this is the old compctl which is
> pretty much unmaintained at this point.

Same problem with:

  autoload -U compinit
  compinit

> However, I'm not able to reproduce this problem on my CentOS 4 box:
> 
> torch% echo $ZSH_VERSION $ZSH_PATCHLEVEL
> 4.3.11-dev-2 1.5265
> torch% ls -a
> .  ..  abcdef
> torch% echo ./{abcdef,

I can't reproduce the problem either under Mac OS X. And I can't
reproduce it under Red Hat with the official zsh 4.3.10.

I've looked at Debian's patches for the zsh package, but I don't
see anything related to the problem here.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-29 00:27:54 +0200, Vincent Lefevre wrote:
> I've looked at Debian's patches for the zsh package, but I don't
> see anything related to the problem here.

I have recompiled the official zsh 4.3.11 under Debian, and have the
same problem with it.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-29 02:31:49 +0200, Vincent Lefevre wrote:
> On 2011-04-29 00:27:54 +0200, Vincent Lefevre wrote:
> > I've looked at Debian's patches for the zsh package, but I don't
> > see anything related to the problem here.
> 
> I have recompiled the official zsh 4.3.11 under Debian, and have the
> same problem with it.

I've done a strace in both cases.

With "echo ./{abc[TAB]", I get:

[...]
16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fff7a4b17f0) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual.zwc", 0x7fff7a4b1760) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", 0x7fff7a4b16d0) = -1 ENOENT (No such file or directory)
16059 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", R_OK) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fff7a4b17f0) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual.zwc", 0x7fff7a4b1760) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", {st_mode=S_IFREG|0644, st_size=858, ...}) = 0
16059 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", R_OK) = 0
16059 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", O_RDONLY|O_NOCTTY) = 3
16059 lseek(3, 0, SEEK_END)             = 858
16059 lseek(3, 0, SEEK_SET)             = 0
16059 read(3, "#autoload\n\n# Test if $1 has glob"..., 858) = 858
16059 close(3)                          = 0
[...]
16059 open("/dev/null", O_WRONLY|O_CREAT|O_NOCTTY|O_TRUNC, 0666) = 3
16059 fcntl(2, F_DUPFD, 10)             = 12
16059 close(2)                          = 0
16059 dup2(3, 2)                        = 2
16059 close(3)                          = 0
16059 open("./", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
16059 getdents(3, /* 3 entries */, 32768) = 80
16059 getdents(3, /* 0 entries */, 32768) = 0
16059 close(3)                          = 0
16059 dup2(12, 2)                       = 2
16059 close(12)                         = 0
[...]
16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fff7a4b0240) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_list_files.zwc", 0x7fff7a4b01b0) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_list_files", 0x7fff7a4b0120) = -1 ENOENT (No such file or directory)
16059 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_list_files", R_OK) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fff7a4b0240) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files.zwc", 0x7fff7a4b01b0) = -1 ENOENT (No such file or directory)
16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files", {st_mode=S_IFREG|0644, st_size=1420, ...}) = 0
16059 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files", R_OK) = 0
16059 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files", O_RDONLY|O_NOCTTY) = 3
16059 lseek(3, 0, SEEK_END)             = 1420
16059 lseek(3, 0, SEEK_SET)             = 0
16059 read(3, "#autoload\n\n# Helper function for"..., 1420) = 1420
16059 close(3)                          = 0
[...]
16059 lstat("./abcdef", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
16059 stat("./abcdef", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[...]

With "echo ./{abcd[TAB]", I get:

[...]
16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fffd1930340) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual.zwc", 0x7fffd19302b0) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", 0x7fffd1930220) = -1 ENOENT (No such file or directory)
16063 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", R_OK) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fffd1930340) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual.zwc", 0x7fffd19302b0) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", {st_mode=S_IFREG|0644, st_size=858, ...}) = 0
16063 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", R_OK) = 0
16063 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", O_RDONLY|O_NOCTTY) = 3
16063 lseek(3, 0, SEEK_END)             = 858
16063 lseek(3, 0, SEEK_SET)             = 0
16063 read(3, "#autoload\n\n# Test if $1 has glob"..., 858) = 858
16063 close(3)                          = 0
[...]
16063 open("/dev/null", O_WRONLY|O_CREAT|O_NOCTTY|O_TRUNC, 0666) = 3
16063 fcntl(2, F_DUPFD, 10)             = 12
16063 close(2)                          = 0
16063 dup2(3, 2)                        = 2
16063 close(3)                          = 0
16063 open("./", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
16063 getdents(3, /* 3 entries */, 32768) = 80
16063 getdents(3, /* 0 entries */, 32768) = 0
16063 close(3)                          = 0
16063 dup2(12, 2)                       = 2
16063 close(12)                         = 0
[...]
16063 access("./acdd", F_OK)            = -1 ENOENT (No such file or directory)
[...]
16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fffd193ab60) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_ignored.zwc", 0x7fffd193aad0) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_ignored", 0x7fffd193aa40) = -1 ENOENT (No such file or directory)
16063 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_ignored", R_OK) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fffd193ab60) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored.zwc", 0x7fffd193aad0) = -1 ENOENT (No such file or directory)
16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored", {st_mode=S_IFREG|0644, st_size=1647, ...}) = 0
16063 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored", R_OK) = 0
16063 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored", O_RDONLY|O_NOCTTY) = 3
16063 lseek(3, 0, SEEK_END)             = 1647
16063 lseek(3, 0, SEEK_SET)             = 0
16063 read(3, "#autoload\n\n# Use ignored matches"..., 1647) = 1647
16063 close(3)                          = 0
[...]

The question is why this access("./acdd", F_OK) in the latter case?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

With "echo ./{abcd", valgrind complains:

==13848== Source and destination overlap in strcpy(0x4027532, 0x4027533)
==13848==    at 0x4C25918: strcpy (mc_replace_strmem.c:311)
==13848==    by 0xD09D92C: get_comp_string (zle_tricky.c:2016)
==13848==    by 0xD098D9C: docomplete (zle_tricky.c:659)
==13848==    by 0xD098126: expandorcomplete (zle_tricky.c:315)
==13848==    by 0xD097D0B: completecall (zle_tricky.c:208)
==13848==    by 0xD0862E0: execzlefunc (zle_main.c:1311)
==13848==    by 0xD085787: zlecore (zle_main.c:1058)
==13848==    by 0xD085EAB: zleread (zle_main.c:1219)
==13848==    by 0xD0888F3: zle_main_entry (zle_main.c:1874)
==13848==    by 0x44B83F: zleentry (init.c:1374)
==13848==    by 0x44C2B4: inputline (input.c:281)
==13848==    by 0x44C12B: ingetc (input.c:217)

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Bart Schaefer]

On Apr 29,  3:34am, Vincent Lefevre wrote:
} Subject: Re: completion on brace + 4 characters doesn't work
}
} With "echo ./{abcd", valgrind complains:
} 
} ==13848== Source and destination overlap in strcpy(0x4027532, 0x4027533)
} ==13848==    at 0x4C25918: strcpy (mc_replace_strmem.c:311)
} ==13848==    by 0xD09D92C: get_comp_string (zle_tricky.c:2016)

That's this line:

   2016                 strcpy(dbeg, dbeg + len);

The code there apparently assumes a naive implementation of strcpy()
that goes left-to-right incrementing the source and destination
pointers in lock step.  There are instances of this assumption all
over the place in get_comp_string().  It would not surprise me to
find this assumption made elsewhere in the zsh sources.

Out of curiosity, does the behavior change if you crank down the
degree of optimization (or up the of debugging) in the compiler flags
when building?

Looking at the patch below, I'm puzzled by the *dbeg = '{' assignments
-- they're to restore the string after a '\0' was plugged into it
temporarily, but isn't *dbeg immediately clobbered by whatever is
at *(dbeg+len) ?  Why bother restoring it?  I suppose len == 0 may
be possible ...

Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Src/Zle/zle_tricky.c,v
retrieving revision 1.30
diff -c -r1.30 zle_tricky.c
--- zle_tricky.c	21 Dec 2010 16:41:16 -0000	1.30
+++ zle_tricky.c	29 Apr 2011 03:45:13 -0000
@@ -1899,7 +1899,7 @@
 			*dbeg = '{';
 			i -= len;
 			boffs -= len;
-			strcpy(dbeg, dbeg + len);
+			memmove(dbeg, dbeg + len, 1+strlen(dbeg+len));
 			dp -= len;
 		    }
 		    bbeg = lastp = p;
@@ -1948,7 +1948,7 @@
 			*dbeg = '{';
 			i -= len;
 			boffs -= len;
-			strcpy(dbeg, dbeg + len);
+			memmove(dbeg, dbeg + len, 1+strlen(dbeg+len));
 			dp -= len;
 		    }
 		    bbeg = NULL;
@@ -2013,7 +2013,7 @@
 		new->qpos = strlen(quotename(predup, NULL));
 		*dbeg = '{';
 		boffs -= len;
-		strcpy(dbeg, dbeg + len);
+		memmove(dbeg, dbeg + len, 1+strlen(dbeg+len));
 	    }
 	    if (brend) {
 		Brinfo bp, prev = NULL;
@@ -2026,7 +2026,7 @@
 		    l = bp->qpos;
 		    bp->pos = strlen(predup + p + l);
 		    bp->qpos = strlen(quotename(predup + p + l, NULL));
-		    strcpy(predup + p, predup + p + l);
+		    memmove(predup + p, predup + p + l, 1+bp->pos);
 		}
 	    }
 	    if (hascom) {

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-28 20:56:57 -0700, Bart Schaefer wrote:
> On Apr 29,  3:34am, Vincent Lefevre wrote:
> } Subject: Re: completion on brace + 4 characters doesn't work
> }
> } With "echo ./{abcd", valgrind complains:
> } 
> } ==13848== Source and destination overlap in strcpy(0x4027532, 0x4027533)
> } ==13848==    at 0x4C25918: strcpy (mc_replace_strmem.c:311)
> } ==13848==    by 0xD09D92C: get_comp_string (zle_tricky.c:2016)
> 
> That's this line:
> 
>    2016                 strcpy(dbeg, dbeg + len);
> 
> The code there apparently assumes a naive implementation of strcpy()
> that goes left-to-right incrementing the source and destination
> pointers in lock step.

It also assumes that the length of the string is less than len
(because the source and the destination may not overlap). The
compiler can use this fact to optimize the code. And as this is
not true, the generated code may be incorrect.

> There are instances of this assumption all
> over the place in get_comp_string().  It would not surprise me to
> find this assumption made elsewhere in the zsh sources.
> 
> Out of curiosity, does the behavior change if you crank down the
> degree of optimization (or up the of debugging) in the compiler flags
> when building?

For the test with valgrind, zsh was compiled with no optimizations,
because I configured it with the option --enable-zsh-debug.

Now, the optimization level doesn't affect the use of GCC builtins
(there's one for strcpy).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-29 10:44:44 +0200, Vincent Lefevre wrote:
> On 2011-04-28 20:56:57 -0700, Bart Schaefer wrote:
> > Out of curiosity, does the behavior change if you crank down the
> > degree of optimization (or up the of debugging) in the compiler flags
> > when building?
> 
> For the test with valgrind, zsh was compiled with no optimizations,
> because I configured it with the option --enable-zsh-debug.
> 
> Now, the optimization level doesn't affect the use of GCC builtins
> (there's one for strcpy).

In fact, the behavior comes from glibc on x86_64. It can be
reproduced with:

#include <stdio.h>
#include <string.h>

int main (void)
{
  static char s[] = "{abcd";
  volatile int len = 1;

  printf ("s = %s\n", s);
  strcpy (s, s + len);
  printf ("s = %s\n", s);
  return 0;
}

and gcc -fno-builtin (the strcpy builtin was not used anyway).

According to gdb, the source in eglibc-2.11.2 is
sysdeps/x86_64/multiarch/strcpy.S (strcpy with SSSE3). It can load
16 bytes at a time, and it uses special code on these 16 bytes (I'm
not sure, but it seems to have code for each length).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Bart Schaefer]

On Apr 29, 10:44am, Vincent Lefevre wrote:
}
} > The code there apparently assumes a naive implementation of strcpy()
} > that goes left-to-right incrementing the source and destination
} > pointers in lock step.
} 
} It also assumes that the length of the string is less than len

Not really, because if the naive copy is done then the only thing
that matters is that len >= 0.

} (because the source and the destination may not overlap).  The
} compiler can use this fact to optimize the code. And as this is
} not true, the generated code may be incorrect.

Yes, I was aware of all this, I just didn't think it was worth spelling
out (it's implicitly not "naive").  Keep in mind that this portion of
zle_tricky.c was written at least 10 years ago by a college student;
zsh was rarely if ever built with highly-optimized compilers/libc on
64-bit platforms, at the time.

Which is why I said:

} > It would not surprise me to
} > find this assumption made elsewhere in the zsh sources.

I don't suppose you could run through the entire "make check" test
suite under valgrind?  Even that won't exercise everything but it'll
find the ones most likely to bite somebody.

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-29 07:20:32 -0700, Bart Schaefer wrote:
> On Apr 29, 10:44am, Vincent Lefevre wrote:
> } > The code there apparently assumes a naive implementation of strcpy()
> } > that goes left-to-right incrementing the source and destination
> } > pointers in lock step.
> } 
> } It also assumes that the length of the string is less than len
> 
> Not really, because if the naive copy is done then the only thing
> that matters is that len >= 0.

Well, you can have a naive strcpy() implementation in the C library,
but still the compiler is allowed to do any optimization, such as
guessing the value of len (or some bounds) from the strcpy() call;
this would not affect the behavior at strcpy(), but may affect the
use of the len variable in some parts of the code.

> } (because the source and the destination may not overlap).  The
> } compiler can use this fact to optimize the code. And as this is
> } not true, the generated code may be incorrect.
> 
> Yes, I was aware of all this, I just didn't think it was worth spelling
> out (it's implicitly not "naive").  Keep in mind that this portion of
> zle_tricky.c was written at least 10 years ago by a college student;
> zsh was rarely if ever built with highly-optimized compilers/libc on
> 64-bit platforms, at the time.
> 
> Which is why I said:
> 
> } > It would not surprise me to
> } > find this assumption made elsewhere in the zsh sources.
> 
> I don't suppose you could run through the entire "make check" test
> suite under valgrind?  Even that won't exercise everything but it'll
> find the ones most likely to bite somebody.

That would be a good idea. There's at least one:

==2490== Invalid read of size 1
==2490==    at 0x430AFE: execcmd (exec.c:3011)
==2490==    by 0x42CAAC: execpline2 (exec.c:1640)
==2490==    by 0x42BC2C: execpline (exec.c:1424)
==2490==    by 0x42B2EA: execlist (exec.c:1207)
==2490==    by 0x431723: execcmd (exec.c:3259)
==2490==    by 0x42CAAC: execpline2 (exec.c:1640)
==2490==    by 0x42BC2C: execpline (exec.c:1424)
==2490==    by 0x42B2EA: execlist (exec.c:1207)
==2490==    by 0x42AD64: execode (exec.c:1028)
==2490==    by 0x4235A5: eval (builtin.c:4908)
==2490==    by 0x423996: bin_eval (builtin.c:5017)
==2490==    by 0x410936: execbuiltin (builtin.c:450)
==2490==  Address 0xc22e213 is not stack'd, malloc'd or (recently) free'd

It occurs in A04redirect.ztst.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-05-02 10:08:39 +0200, Vincent Lefevre wrote:
> On 2011-04-29 07:20:32 -0700, Bart Schaefer wrote:
> > I don't suppose you could run through the entire "make check" test
> > suite under valgrind?

FYI, this can be done with:

  valgrind --trace-children=yes make check

> > Even that won't exercise everything but it'll
> > find the ones most likely to bite somebody.
> 
> That would be a good idea. There's at least one:
> 
> ==2490== Invalid read of size 1
> ==2490==    at 0x430AFE: execcmd (exec.c:3011)
> ==2490==    by 0x42CAAC: execpline2 (exec.c:1640)
> ==2490==    by 0x42BC2C: execpline (exec.c:1424)
> ==2490==    by 0x42B2EA: execlist (exec.c:1207)
> ==2490==    by 0x431723: execcmd (exec.c:3259)
> ==2490==    by 0x42CAAC: execpline2 (exec.c:1640)
> ==2490==    by 0x42BC2C: execpline (exec.c:1424)
> ==2490==    by 0x42B2EA: execlist (exec.c:1207)
> ==2490==    by 0x42AD64: execode (exec.c:1028)
> ==2490==    by 0x4235A5: eval (builtin.c:4908)
> ==2490==    by 0x423996: bin_eval (builtin.c:5017)
> ==2490==    by 0x410936: execbuiltin (builtin.c:450)
> ==2490==  Address 0xc22e213 is not stack'd, malloc'd or (recently) free'd
> 
> It occurs in A04redirect.ztst.

This is the only error. It can simply be reproduced by:

  myfd=99
  (echo >&$myfd) 2>msg

after zsh -f.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: completion on brace + 4 characters doesn't work

[Peter Stephenson]

On Mon, 2 May 2011 10:34:43 +0200
Vincent Lefevre <vincent@vinc17.net> wrote:
> This is the only error. It can simply be reproduced by:
> 
>   myfd=99
>   (echo >&$myfd) 2>msg
> 
> after zsh -f.

Thanks, this fixes that problem.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.192
diff -p -u -r1.192 exec.c
--- Src/exec.c	6 Mar 2011 21:37:38 -0000	1.192
+++ Src/exec.c	2 May 2011 11:53:33 -0000
@@ -3008,10 +3008,11 @@ execcmd(Estate state, int input, int out
 		if (!checkclobberparam(fn))
 		    fil = -1;
 		else if (fn->fd2 > 9 &&
-		    ((fdtable[fn->fd2] != FDT_UNUSED &&
-		      fdtable[fn->fd2] != FDT_EXTERNAL) ||
-		     fn->fd2 == coprocin ||
-		     fn->fd2 == coprocout)) {
+			 (fn->fd2 > max_zsh_fd ||
+			  (fdtable[fn->fd2] != FDT_UNUSED &&
+			   fdtable[fn->fd2] != FDT_EXTERNAL) ||
+			  fn->fd2 == coprocin ||
+			  fn->fd2 == coprocout)) {
 		    fil = -1;
 		    errno = EBADF;
 		} else {

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre]

On 2011-04-29 13:15:58 +0200, Vincent Lefevre wrote:
> In fact, the behavior comes from glibc on x86_64. It can be
> reproduced with:
> 
> #include <stdio.h>
> #include <string.h>
> 
> int main (void)
> {
>   static char s[] = "{abcd";
>   volatile int len = 1;
> 
>   printf ("s = %s\n", s);
>   strcpy (s, s + len);
>   printf ("s = %s\n", s);
>   return 0;
> }
> 
> and gcc -fno-builtin (the strcpy builtin was not used anyway).
> 
> According to gdb, the source in eglibc-2.11.2 is
> sysdeps/x86_64/multiarch/strcpy.S (strcpy with SSSE3). It can load
> 16 bytes at a time, and it uses special code on these 16 bytes (I'm
> not sure, but it seems to have code for each length).

FYI, this new strcpy code breaks many applications:

  http://sourceware.org/bugzilla/show_bug.cgi?id=12518

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)